Load Balancing Monitor Groups: Multi-Service Health Checks for Resilient Applications

Beyond the Single Health Check

Distributed applications rarely fail as a single unit. A front-end web server can be fully responsive while the database it depends on, or the API gateway it routes through, has already gone dark. In that state, the application is effectively down for users, even though a basic health check on the web server itself reports everything is fine. Relying on one probe gives you an incomplete, sometimes misleading, view of your actual service availability.

Cloudflare is addressing this with a new feature for its Load Balancing product: Monitor Groups. Now available via API for Enterprise customers, this feature allows you to bundle multiple individual health monitors into a single logical entity that can be attached to a pool of origin servers. Instead of running a separate aggregation service to stitch together different health signals—which adds operational complexity and becomes another potential failure point—you can define these checks directly on Cloudflare’s edge network.

The feature is designed to give you granular control over how a pool’s health is calculated across multiple checks. When you define a Monitor Group, you assign its members specific roles that influence failover logic.

// Structure for a single monitor within a group
{
  "description": "Test Monitor Group",
  "members": [
    {
      "monitor_id": "string",
      "enabled": true,
      "monitoring_only": false,
      "must_be_healthy": true
    },
    {
      "monitor_id": "string",
      "enabled": true,
      "monitoring_only": false,
      "must_be_healthy": true
    }
  ]
}

Monitor Group Mechanics

Monitor Groups act as a superset of standard monitors. You build your individual HTTP, TCP, and other monitors as usual, then combine them into one group. When attached to a pool, the group’s members aggregate their results to determine the health of each origin in that pool. You can combine up to five monitors in a single group.

The logic that turns individual probes into a collective verdict is controlled by three key settings in the group’s members array:

• Critical monitors (must_be_healthy): If a monitor marked as critical fails against an endpoint, that endpoint is immediately marked unhealthy, no matter how the other monitors report.
• Observational probes (monitoring_only): These members record data and trigger alerts but do not affect traffic steering or the pool’s health state. This is a safe way to test a new check without risking production traffic.
• Quorum-based health: When no critical monitor has failed, an endpoint’s health comes down to a vote. It is only marked globally unhealthy if more than 50% of the active, non-observational monitors report it as down. This tolerates a single transient blip on one non-essential service without triggering an unnecessary failover.

Health Checks From Everywhere

These checks aren’t run from one location. You can configure the Monitor Group to run probes from multiple regions, or even from every data center across Cloudflare’s global network in over 300 cities. For most applications, Cloudflare recommends picking a small number of diverse regions (such as Western North America plus Eastern Europe), or using the 'All Regions' setting. This gives you a geographically distributed consensus on your application’s health without flooding your origins with extra monitoring traffic.

This distributed perspective also sharpens Cloudflare’s Dynamic Steering. Instead of calculating steering latency from a single service’s round-trip time, the load balancer now averages the RTT across all active, non-observational members in the Monitor Group, pulled from potentially hundreds of points of presence. The result is a stability that prevents traffic from bouncing due to a fleeting latency spike from one isolated, non-critical interface.

An Example of Aggregated Health

To see how a multi-layered decision gets made, consider an application with three checks: an HTTP probe on a public /health endpoint, a TCP probe on Port 3000, and a database dependency check. The database check is protected from the public internet via a Cloudflare Tunnel.

Setup Configuration

• Monitors:
  • HTTP check for /health (must_be_healthy: true)
  • TCP check for Port 3000 (must_be_healthy: false)
  • DB check for database health (must_be_healthy: false)
• Regions: Western North America (3 data centers) and Eastern North America (3 data centers)

On a per-data-center basis, the logic is strict: if the critical HTTP probe fails, that data center is definitively DOWN. Otherwise, its verdict comes from the majority status of the other two monitors.

At the endpoint level, the final decision is a majority vote across all six data centers.

• Data center votes: 5 of 6 report UP because only one location experienced the critical HTTP failure.
• Global result: With 5 out of 6 data centers reporting healthy (83%, above the 50% quorum), the endpoint remains in rotation.

Had a single non-critical monitor failed across multiple regions instead, the endpoint still has a buffer: it is only taken out of service when more than half of the checking data centers deem it unhealthy.

Getting Started

To create a Monitor Group, send a POST request to the new /load_balancers/monitor_groups endpoint.

POST accounts/{account_id}/load_balancers/monitor_groups
{
  "description": "Monitor group for checkout service",
  "members": [
    {
      "monitor_id": "string",
      "must_be_healthy": true,
	"enabled": true
    },
    {
      "monitor_id": "string",
      "monitoring_only": false,
	"enabled": true
    }
  ]
}

After the group is created, attach it to a pool by referencing its ID in the monitor_group field of the pool object.

Monitor Groups are currently limited to Enterprise customers with Cloudflare Load Balancing, but the feature is slated to roll out to the dashboard and self-serve plans in the near future. Cloudflare is also extending the platform with more flexible role-based access controls and enhanced load-based steering capabilities. In the meantime, full API reference and implementation details are available in the developer documentation.