TTL Check Heartbeat Frequency Limits in Consul

TTL Check Behavior

In Consul, TTL checks require the service to send periodic heartbeats to keep the check in a passing state. If the heartbeat is not received within the TTL window, the check automatically transitions to critical. This mechanism shifts the monitoring responsibility from the Consul agent to the service itself.

When many services register TTL checks, the aggregate heartbeat traffic can increase load on the local agent’s RPC interface. Network partitions between a service and its agent can also cause false positives, as the agent may not receive heartbeats even though the service is healthy.

Additionally, the deregister_critical_service_after setting can automatically remove services that remain in a critical state for a defined duration, but its interaction with the TTL window is not fully documented.

Unresolved Questions

• What is the recommended maximum heartbeat frequency per service to avoid overloading the agent, especially under high service counts?
• Can TTL heartbeats be batched or aggregated to reduce RPC load, and if so, how does Consul handle the timing of such batched heartbeats?
• How does the deregister_critical_service_after setting affect the transition from passing to critical when heartbeats are intermittently missed?