The most common GTM mistake is managing data-centre health with a single up/down flag. In reality a data centre can be reachable while the application is down; the application can respond while the database is not working; the WAN link can be open while LAN-side access has failed. A single-flag health model cannot capture these distinctions.
In many organisations the link between health checks and DNS responses is manual or fragmented. A monitoring system raises an alert, an operations team runs a script, a DNS record is updated by hand or a separate automation takes over. This chain reacts slowly and is vulnerable to human error at critical moments.
Complex scenarios are even harder. Conditions such as "activate DC1 if it has internet access and is not in maintenance; otherwise return a backup record if DC2 application health or DC3 access is positive" are usually managed through YAML files, scripts and manual dependencies. This turns a GTM decision into an operational labyrinth that is difficult to understand or audit.
Flapping is a real risk. When a health check fails momentarily and DNS changes immediately, user traffic is moved to another region unnecessarily. Likewise, a brief success can pull traffic back before the problem is fully resolved. Consecutive success and failure thresholds plus state-preservation logic are therefore essential.
TR7 health check scenarios combine data-centre, application, database, maintenance mode and custom checks into a single boolean decision layer, binding DNS responses directly to real service health.
TR7 evaluates GTM health decisions by combining automatic data-centre checks, manual health checks and scenario logic in a unified model.
Per-data-centre automatic checks, user-defined HTTP/HTTPS/Oracle checks and ADC health results can all be used within the same decision structure. This binds infrastructure and application health into a single GTM decision.
Scenarios are built with AND and OR groups. Appending `!` to a health-check identifier negates the condition, so states such as maintenance mode can be used as negative conditions in the same decision.
Health check, scenario and DNS record relationships are tracked through graph-style maps. When a health state changes, only the impacted scenarios and records are re-evaluated.
HTTP and HTTPS health checks can verify status codes and response content, not only whether a port is open. JSONata expressions or simple content checks confirm that the application is genuinely returning a healthy response.
TR7 Health Check Scenarios cover a range of GTM needs — from simple access checks to multi-layer application and data-centre decisions.
TR7 supports parameters such as method, URI, body, headers, expected status codes, certificate verification and timeout for HTTP and HTTPS checks. The check therefore does not just measure whether a connection can be established — it also verifies that the application is returning the correct response from the correct endpoint, bringing the GTM decision closer to real application behaviour.
For health endpoints that return JSON, specific fields can be evaluated using a JSONata expression. An expression such as `status = "ok"` confirms not only that the application responds but that it returns the expected health state. The response body is parsed into the appropriate structure and the expression is evaluated against it. This gives more reliable health measurement for modern JSON API-based applications.
For more straightforward scenarios, the response body can be checked for the presence of a specific string. This approach is sufficient for simple application health checks that do not require a full JSONata expression. Operations teams can bind the DNS decision to the confirmation that a known word or fixed state appears in the application response, making checks quick and easy to understand.
Oracle checks are configured through a scenario that includes steps for establishing a connection, waiting and executing a command. Results are evaluated based on an expected row count or expected text. This allows DNS responses to be tied not only to the application tier but also to database reachability, reducing the blind spot of "application is up but the database is not working" in critical business applications.
TR7 can use `wanAccess`, `lanAccess`, `access`, `internet` and `maintenanceMode` checks on a per-data-centre basis. These checks represent different access and operational states of each data centre independently. States such as maintenance mode can be treated as negative conditions in a scenario rather than as positive health signals, giving DNS decisions a closer match to operational reality.
Scenarios are built with condition group structures; conditions within a group follow AND logic while inter-group relationships can be OR or AND. Appending `!` to a health-check identifier inverts the condition, enabling constructs such as `dcAccess AND NOT maintenanceMode`. Complex GTM decisions can be designed without writing scripts.
`requiredSuccess` and `requiredFailure` values can be configured for health checks. The default approach counts consecutive successes or failures before a state transition is accepted. This prevents momentary packet loss, brief latency spikes or transient service fluctuations from immediately changing the DNS response, making GTM behaviour more stable.
Health check states can be persisted to a local file and restored when the system restarts. This means that all health states do not need to be re-learned from scratch after every restart. This continuity is especially important in larger GTM environments with many scenarios and records, giving operations teams more predictable behaviour after a restart.
TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS and Oracle health checks are available in the TR7 ecosystem. Coordinating GTM and ADC health results lets DNS decisions reflect the true state of the service layer. This broad type support makes it possible to build a health model not only for web applications but for multi-protocol enterprise services. Script-like TCP send-receive scenarios are also available for custom check requirements.
For health check scenarios to work reliably, identifier format, state persistence, trigger sequence, master-node control and change propagation must all be clearly managed.
The scenario engine can evaluate health check types including static, dcCheck, http, https and oracle. Combined with the broader GTM and ADC health check family, multi-protocol service states can be brought into the decision structure — important for service architectures that are not limited to a single HTTP check type.
Per-data-centre automatic health checks are identified using the format `auto|
User-defined health checks are created with unique identifiers. These identifiers can be referenced directly in scenario conditions, meaning the same HTTP, HTTPS or Oracle check can be evaluated across multiple GTM scenarios.
When a health state changes, the relevant health check state is updated first. Linked scenarios are then re-evaluated and, if necessary, the dynamic configuration is regenerated. This flow ensures that changes propagate to DNS responses in a controlled manner.
Built-in scenarios such as `ALWAYS` and `NEVER` are available for producing fixed decisions. With `ALWAYS`, a record is always considered eligible; with `NEVER`, disabled behaviour is achieved. This is useful for testing, temporary takedowns or unconditional routing.
Trigger actions are executed only on the GTM master node. This prevents the same action from being run repeatedly by multiple nodes in a cluster. For actions such as DR triggering, webhooks or notifications, this control provides operational safety.
Multi-site organisations may not want a data centre to be considered up based on a single access path. TR7 combines different access routes into the same DNS decision using scenarios such as `wanAccess OR lanAccess`.
For critical business applications, data-centre reachability alone is not enough. TR7 uses scenarios such as `dcAccess AND appHC AND dbHC` to include the relevant IP in the DNS response only when both the application and the Oracle database are healthy.
An operations team may not want a data centre to receive traffic during maintenance even if it is technically reachable. TR7 can remove a maintenance location from the DNS response using a scenario such as `dcAccess AND NOT maintenanceMode`.
Modern applications can publish their health state through a JSON endpoint. TR7 binds DNS responses to real application health by combining an HTTPS health check with a JSONata expression such as `status = "ok"`.
Combine HTTP, HTTPS, Oracle and data-centre checks into boolean scenarios. Let us walk through a live setup in your own environment.