Build Monitoring uptime check configurations with HTTP/HTTPS checks, content matchers, and multi-region probing.
Build Monitoring uptime check configurations with HTTP/HTTPS checks, content matchers, SSL validation, and multi-region probing.
Required Fields
displayNamemonitoredResourcehttpCheck.pathperiodtimeoutOutput will appear here...The builder requires displayName, monitoredResource, httpCheck.path, period, and timeout to resolve before accepting the config, the fields the Monitoring API needs to actually schedule a check, everything else (content matchers, SSL validation, checker type, regions) is validated as structurally correct JSON but the semantic choices are yours to make based on where the target actually lives.
Build a Cloud Monitoring uptime check configuration with HTTP checks, content matchers, SSL validation, and multi-region probing. The check period is constrained to one of four fixed values (60s, 300s, 600s, or 900s), you can't set an arbitrary interval like 30s, and timeout must be less than or equal to the period or the check is rejected outright. checkerType STATIC_IP_CHECKERS uses Google's published, documented IP ranges (useful when the target is behind a firewall that allowlists specific source IPs), while VPC_CHECKERS run from inside your own VPC for probing private, internal-only endpoints that aren't internet-reachable at all.
A platform team migrates an internal admin dashboard behind a private load balancer with no public ingress at all, and copies the existing uptime check config for the old public version without changing checkerType, leaving it on the default STATIC_IP_CHECKERS. The check immediately starts firing false-positive down alerts every few minutes, paging on-call for an outage that isn't real, since Google's public checkers simply can't route to a private-only endpoint. They use the builder to switch checkerType to VPC_CHECKERS and set isInternal true, and the check starts correctly reflecting the dashboard's actual health from inside the VPC.
timeout must be less than or equal to period, a config with timeout: 60s and period: 60s is right at the edge and will fail creation the moment you nudge timeout even slightly higher, leave meaningful headroom between the two.
An internal endpoint checked with the default STATIC_IP_CHECKERS mode doesn't fail with an informative error, it just times out repeatedly, looking exactly like an outage, when the actual problem is that public checkers can never reach a private target in the first place.
selectedRegions affects both failure-detection latency (fewer regions means slower consensus on 'is this really down') and check cost, since each region runs an independent probe, six regions isn't automatically better than two if you don't need that level of geographic redundancy.
No, period only accepts 60s, 300s, 600s, or 900s, there's no finer granularity available. For faster detection than 60s allows, you'd need a different tool (an external synthetic monitoring service, or your own lightweight health-check loop) layered alongside Cloud Monitoring uptime checks rather than trying to tune this setting past its floor.
If the target sits behind a firewall or WAF with IP allowlisting, the check's probing IPs (which come from Google's published static ranges for STATIC_IP_CHECKERS) need to be explicitly allowed. A browser request from your own IP succeeding while the uptime check fails is the classic signature of the check's source IPs being blocked at the network edge.
acceptedResponseStatusCodes checks the HTTP status class (e.g., 2XX) and fails on anything outside it, catching outright errors. contentMatchers inspects the response body for a specific string, absence, or regex match, catching cases where the server returns a healthy-looking 200 but the payload itself indicates a problem, like a health endpoint that returns 200 with {"status":"degraded"} in the body.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.