GCP Uptime Checks Explained: Public vs Private, Alerting

Simple explanation

An uptime check is a scheduled probe. Google’s infrastructure regularly sends a request to a URL or TCP port you specify, then records whether it got the expected response. That is the whole mechanism. The value is that these probes come from outside your infrastructure, so they catch failures your internal metrics cannot see: a misconfigured load balancer, a DNS entry pointing at a dead IP, or a firewall rule that silently dropped traffic.

Public uptime checks probe endpoints reachable from the public internet. Private uptime checks probe internal VPC endpoints using a checker deployed inside your own network. Both feed results into Cloud Monitoring, where you attach alerting policies to them.

The core limitation: uptime checks validate reachability and response codes. They do not validate application correctness. A passing check tells you the door is open. It tells you nothing about what is happening inside.

Quick answer

What uptime checks actually test

Your internal metrics can look healthy while your service is completely unreachable. If your load balancer has a misconfigured SSL certificate, your DNS entry points at a dead IP, or a firewall rule is blocking traffic, your application containers may be running fine but users cannot get to them. Uptime checks catch this class of failure because they probe from outside your infrastructure.

Specific failures uptime checks detect:

• DNS resolution failures
• SSL certificate errors or expiry
• TCP connection refused (port not open or firewall blocking)
• HTTP 5xx responses from the load balancer or CDN layer
• Timeout because the service is not responding within the window
• Response body content mismatches (if you configure content matching)
• Redirect loops or unexpected redirect destinations (if you configure redirect following)

What uptime checks do NOT catch:

• Application logic errors that still return 200
• Slow database queries causing high latency without causing timeouts
• Background job failures
• Partial outages affecting some users but not the health endpoint
• Memory leaks that have not yet caused failures
• Whether application logic is correct, only that a response arrived

Public vs private uptime checks

Cloud Monitoring supports two modes of uptime check. Choosing the wrong one is a common setup mistake that produces checks that never succeed.

Public uptime checks

Public checks probe from Google-managed global infrastructure to any publicly accessible endpoint on the internet. The target must have a public IP address or hostname. No setup is required inside your network; you just provide a URL or hostname.

Use public checks for:

• Publicly accessible web applications and APIs
• Cloud Run services behind a load balancer
• Any endpoint your users reach from the internet

Private uptime checks

Private checks probe internal endpoints that are not reachable from the public internet. They work through a private checker: a small agent you deploy inside your VPC that receives probe instructions from Cloud Monitoring and tests your internal services locally. Results are reported back through standard GCP APIs.

Use private checks for:

• Internal microservices with no public IP
• Databases and backend services inside a VPC
• GKE workloads not exposed via an external load balancer
• Services on private VPCs or behind internal internal load balancers

Private uptime checks are generally available (GA) in Cloud Monitoring. They require creating a private checker resource and granting it permissions in your project. For most internal service monitoring, private checks are simpler to set up than a full synthetic monitor, but less flexible.

How uptime checks work

When you create an uptime check, Cloud Monitoring schedules probes from multiple geographic locations simultaneously. Google operates check infrastructure across North America, South America, Europe, and Asia-Pacific (typically six locations for public checks).

Each probe independently sends the configured request and evaluates the response:

• Success: response received within the timeout window, status code matches the expected value (default: any 2xx), and content match passes if configured
• Failure: connection refused, timeout, unexpected status code, SSL error, or content mismatch

The per-location results are what make uptime checks useful for diagnosing partial outages. If your service is failing only from Europe, that points to a routing or regional issue, not a complete outage. The location breakdown narrows your investigation immediately, which is exactly what matters when debugging production incidents.

Uptime check results are different from application metrics like request latency or error rate. Metrics measure what your service is doing internally. Uptime checks measure whether an external probe can reach it at all. Both are necessary for complete observability.

Check types

HTTPS

Sends an HTTPS request (GET by default, configurable to POST) to a URL. Validates the response code, checks SSL certificate validity, and optionally matches response body content. This is the most common type and the right default for any web-facing service. It validates the full TLS handshake, so a misconfigured or expired certificate shows up immediately as a failure.

HTTP

Same as HTTPS but over plain HTTP. Use this only for services that do not support TLS, such as internal-only endpoints or legacy services. For anything public-facing, prefer HTTPS so the check validates your certificate as well as reachability.

TCP

Opens a TCP connection to a host and port. No HTTP request is sent; it only verifies the port is accepting connections. Useful for non-HTTP services where you need to confirm the port is open: a message broker, a database proxy, or a custom protocol service. TCP checks work for both public and private endpoints (private requires a private checker).

When to use uptime checks

• Monitoring any public-facing endpoint where you need to know immediately if it becomes unreachable
• Catching SSL certificate expiry before it affects users
• Detecting DNS failures or misconfiguration
• Monitoring internal VPC services that do not need a full synthetic test (use private checks)
• As a baseline check for Cloud Run services, paired with request error rate metrics for complete coverage
• As part of incident response tooling to get a fast, external view during active outages
• Setting up a smoke test after a deployment to confirm the new version is serving traffic

When not to rely on uptime checks alone

Uptime checks are necessary but not sufficient for production observability. You still need:

• Application metrics: error rate, latency, saturation, and traffic volume from Cloud Monitoring metrics. A passing uptime check means the service is reachable. High error rates in metrics mean users are still hitting failures.
• Logs: Logs Explorer gives you the actual error messages and stack traces when something goes wrong. Uptime checks tell you the door is closed; logs tell you why.
• Traces: If a service is slow but not failing, uptime checks will not detect it. Distributed tracing shows which service in a chain is causing latency.
• Synthetic monitors: If you need to validate a multi-step user flow (login, search, checkout), a synthetic monitor tests the full journey. An uptime check only tests one endpoint.

Uptime checks vs load balancer health checks vs synthetic monitors

These three tools are often confused because they all involve checking whether something is healthy. They test different things from different vantage points.

How to create an uptime check

The simplest path is the Cloud Monitoring console: navigate to Monitoring > Uptime checks > Create uptime check. The console walks you through selecting the check type, specifying the target, configuring optional content matching, and creating an alerting policy at the same time. Accept the offer to create an alert. An uptime check without an alert is just data collection.

For public HTTPS and TCP checks, the gcloud CLI works too:

# Create a public HTTPS uptime check with 1-minute frequency
gcloud monitoring uptime create \
  --display-name="API Health Check" \
  --uri="https://api-service-xxxx-ew.a.run.app/health" \
  --period=60 \
  --project=my-app-prod

# Create a public TCP uptime check on a public host and port
gcloud monitoring uptime create \
  --display-name="App TCP Port Check" \
  --tcp-host=203.0.113.10 \
  --tcp-port=8080 \
  --period=300 \
  --project=my-app-prod

# List all uptime checks in a project
gcloud monitoring uptime list-configs --project=my-app-prod

What to point the check at

Point uptime checks at a dedicated /health or /healthz endpoint. A good health endpoint:

• Returns HTTP 200 when the service is ready to handle requests
• Returns a non-200 status (typically 503) when the service is degraded or not ready
• Is lightweight: no database queries, no external calls, only confirms the process is alive
• Returns a simple response body like {“status”: “ok”} that the uptime check can optionally validate with content matching

Shallow vs deep health endpoints

A shallow health endpoint checks only that the process is running and can respond. No dependencies. This is what your uptime check should target. Failures mean the service itself is unreachable, not that a downstream database is slow.

A deep health endpoint checks that dependencies (database, cache, external APIs) are also healthy. Useful for load balancer health checks or separate alerting policies, but do not target it with your basic uptime check.