A typical health check sends a request to an endpoint, sees a 200 response and marks the service healthy. In modern applications this is not enough. The application homepage may respond while the database connection is slow, the cache layer is broken, a downstream dependency has gone down or the login flow has stopped working. If the load balancer cannot see this difference it keeps routing traffic to backends that respond but cannot do real work.
Single-step checks fall even shorter for session-based protocols. For FTP, LDAP, Oracle or custom TCP protocols, having the port open does not mean the service is healthy. A real health check must log in, send a command, receive the expected response, log out if needed and validate the response content. Otherwise the service looks reachable while real user operations fail.
Content validation becomes brittle when it is limited to plain-text matching. An API may always return the word "OK" while the dependency state, latency metric or business rule inside the JSON is failing. When a health check cannot query the meaning of the response, application-level degradations are caught late.
The right approach is to address health checks with protocol depth, multi-step scenarios, content queries and configurable rise/fall thresholds. Probe operations must run isolated from the main traffic flow so that slow or stalled health checks do not delay user traffic.
TR7 Active Health Monitoring delivers this model: it monitors 11 protocols from a single configuration, executes multi-step scenarios, validates content meaning with JSONata and keeps only genuinely healthy targets in rotation.
TR7 transforms health checking from a single-protocol control into a multi-protocol, scenario-based and content-validated decision system.
TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS and Oracle checks are all managed from the same health check object. Depending on the selected checkType, only the relevant fields are shown, so operators are not burdened with irrelevant parameters.
For TCP, UDP and Oracle checks, ordered control flows are built using send, expect, regex and wait steps. If any step fails, the probe is marked failed and the backend health state is updated accordingly.
For HTTP and HTTPS checks, JSONata queries are used to read the real state inside a JSON response. A backend is not considered healthy merely for returning 200 — fields such as dependency status, score, latency or business state can also be checked.
The number of consecutive failed responses required to mark a backend unhealthy and the number of consecutive successful responses required to bring it back are configured independently. This prevents transient network fluctuations from continuously cycling backends in and out of rotation.
Active Health Monitoring makes diverse service types definable, testable and manageable with operational thresholds — all from the same editor.
TR7 supports TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS and Oracle health checks. Operators do not need separate tools for an Oracle database, LDAP directory, DNS server, FTPS repository or HTTP API. Relevant fields appear based on the selected protocol type; unrelated fields are hidden. This model makes health checking across heterogeneous backends standardized and maintainable.
For TCP checks, sendText, expectText, expectRegex and wait steps can be run in sequence. SMTP banners, IMAP capability queries, Redis PING/PONG exchanges, MQTT responses and custom TCP protocol messages are all testable with this model. Instead of merely opening a connection, a real protocol dialogue is executed. If any step does not produce the expected result, the backend is marked unhealthy.
For UDP checks, send, wait, expectText and expectRegex steps are available. The data to send can be defined in text, hex or base64 format, providing flexibility for binary protocol probes. For DNS, NTP, RADIUS, SIP and similar UDP services, the expected protocol response is validated — not just whether the port is open. This makes UDP services actively and meaningfully monitorable.
HTTP/HTTPS health checks support method, URI, custom header list, request body and virtual host. An API endpoint can be probed with an Authorization header, JSON body or custom Host header. Acceptable status codes do not have to be a single value — 200, 204 or 304 can all be considered healthy. This design brings health checking closer to real application usage.
When contentCheckMode is set to jsonata, the response body is evaluated as JSON and the JSONata expression is executed. Service status, dependency result, database latency or a business metric can all be checked within a single expression. If the expression produces a truthy result the backend is healthy; a falsy result marks it failed. JSONata errors are logged so that a wrong expression or unexpected response structure becomes visible.
For simple scenarios that do not require JSONata, contentQuery performs a text search inside the response body. Marker strings such as "Welcome", "UP" or "Service Ready" — or application-specific text — can be checked quickly. This mode offers a low-complexity solution for simple health endpoints or legacy applications. Operators choose between basic check and JSONata based on the scenario.
LDAP/LDAPS checks can test not only port access but the real bind operation. A bind performed with a username and password validates the directory service at the authentication level. Even if the port is open, a backend can be marked unhealthy if the bind queue, authorization or service has a problem. This provides critical visibility especially for AAM and enterprise access flows.
Oracle health checks support connection details, username, password and scenario steps. SQL is executed via executeCmd and the expected text or minimum row count is verified. Instead of a simple connection test, real data access and business metrics can be queried. This approach makes the question of database availability meaningful from the application's perspective.
Health checks operate together with interval, timeout, threshold, scenario composition, instance identity and system-internal specialized controls.
testInterval is configurable from 0.5 to 3600 seconds; the default is 1 second. timeout is configurable from 0.01 to 3600 seconds. Aggressive timeout enables faster failover but can increase false-positive risk and should be tuned to service behavior.
requiredFailure defaults to 2; requiredSuccess defaults to 3. These thresholds determine how quickly a service is removed from rotation and how cautiously it is returned. Both sides of the threshold are managed independently to filter transient fluctuations.
A single health check can combine multiple atomic checks using AND/OR logic. This means that not just a single probe result but multiple dependencies or protocol steps can be evaluated together. Complex service health is modeled more realistically.
The same health check maintains separate state for each backend. The health check instance ID is differentiated by check and target. This means that even when the same check profile is applied to multiple targets, each target's health history is tracked independently.
The negate setting reverses the normal success logic. This mode is used when a specific URL is expected to be unreachable, a specific response is expected not to be returned, or a service path is expected to remain inaccessible. A successful response is treated as a failure; a failed response is treated as a success.
System-internal health checks such as gateway monitors and cluster IP connection checks can be generated automatically. These checks are used to monitor not only application backends but also the connectivity and upstream reachability around TR7. The model can be extended with additional check types such as datacenter checks on the GTM side.
An e-commerce team can use an HTTP check with JSONata to verify not just that the cart service returns 200 but also that database latency and availability metrics are within bounds. A slow or dependency-degraded backend is automatically removed from rotation.
Bank teams can use Oracle checks to go beyond opening a connection and actually execute real SQL queries. If the expected row count or query result is not met, the backend is marked unhealthy and traffic is directed to safe targets.
Government applications can verify that a directory service is working not just at the port level but through a real bind operation. If the port is open but authentication fails, the system treats this as a health problem.
Telecom teams can run real record queries for a critical domain using a DNS check. Having the DNS port open is not sufficient — the resolver must produce the expected answer to be considered healthy.
Base your traffic decisions on reliable health data across 11 protocols, multi-step scenarios and JSONata content validation. Let's walk through a live setup on your own services.