Health check logging information

You can get logs of load balancinghealth checks when an endpointchanges in health status. You can use health check logs for the following:

  • Live debugging and troubleshooting your endpoint health status
  • Getting visibility into your endpoint's health status
  • Auditing and compliance purposes

Health checks log health transition information toLogging.You enable or disable logging on a per-health check basis.

To see health check logs in Logging, you must ensure that youdon't have a logs exclusion that applies to health checks. For instructionsabout how to verify thatGCE Instance Group andNetwork Endpoint Group logs are allowed, seeExclusion filters.

Enable and disable logging

This section describes how to enable logging on a new or an existinghealth check, and how to disable logging on an existing health check.

Enable logging on a new health check

Console

  1. In the Google Cloud console, go to theHealth checks page.

    Go to Health checks

  2. ClickCreate health check.

  3. ForLogs, selectOn.

  4. Continue setting up your health check.

gcloud

gcloud compute health-checks createPROTOCOLHEALTH_CHECK_NAME \    --enable-logging

The flag--enable-logging enables logging for that health check.

Terraform

To create a health check for different protocols with logging, use thegoogle_compute_health_check resource.

resource "google_compute_health_check" "health_check_tcp_with_logging" {  provider = google-beta  name = "health-check-tcp"  timeout_sec        = 1  check_interval_sec = 1  tcp_health_check {    port = "22"  }  log_config {    enable = true  }}

For a regional load balancer, use thegoogle_compute_region_health_check resource.

To learn how to apply or remove a Terraform configuration, seeBasic Terraform commands.

Enable logging on an existing health check

Console

  1. In the Google Cloud console, go to theHealth checks page.

    Go to Health checks

  2. Click the name of your health check.

  3. ClickEdit.

  4. ForLogs, selectOn.

  5. ClickSave.

gcloud

gcloud compute health-checks updatePROTOCOLHEALTH_CHECK_NAME \    --enable-logging

The flag--enable-logging enables logging for that health check.

Disable logging on an existing health check

Console

  1. In the Google Cloud console, go to theHealth checks page.

    Go to Health checks

  2. Click the name of your health check.

  3. ClickEdit.

  4. ForLogs, selectOff.

  5. ClickSave.

gcloud

gcloud compute health-checks updatePROTOCOLHEALTH_CHECK_NAME \    --no-enable-logging

The flag--no-enable-logging disables logging for that health check.

View logs

  1. To view logs, go to theLogs explorer.

    Health check logs are indexed byinstance group ornetwork endpoint group.

  2. To see all logs, in theResource menu, select eitherGCE Instance Group orNetwork Endpoint Group, depending on the type of backend.

  3. Alternatively, paste the following into theQuery field. ReplacePROJECT_ID with your project's ID.

    logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"

You can configure export oflogs-based metrics for load balancerhealth checks.

Use filters to view logs

You can also get logs based on more specific searches. For example, thefollowing filter shows all logs for a specified backend instance IP address:

  logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"jsonPayload.healthCheckProbeResult.ipAddress="IP_ADDRESS"

Log fields of typeboolean typically only appear if they have a value oftrue.If a boolean field has a value offalse, that field is omitted from the log.

UTF-8 encodingis enforced for log fields. Characters that are not UTF-8characters are replaced with question marks.

What is logged

Health check log entries contain information useful for monitoringand debugging the state of your endpoints. Log entries contain the followingtypes of information:

  • General information shown in most logs, such as severity, project ID,project number, and timestamp.
  • Fields specific to health checks, described in the following tables.

Health check states

An endpoint is considered eitherHEALTHY orUNHEALTHY. These are the basicstates. Within each of these basic states, there are several more detailedstates.

Hybrid NEGs and regional internet NEGs using distributed Envoyhealth checks do not support detailed health states.

The following table shows the mapping between basic and detailed health states.

Basic health stateDetailed health state
HEALTHYHEALTHY
DRAINING
UNHEALTHYUNKNOWN
UNHEALTHY
TIMEOUT

State changes don't always alter the behavior of the load balancer. Consider thefollowing case:

  1. The server is giving the wrong response, so the endpoint is consideredUNHEALTHY.
  2. The server then stops responding, and the new state isTIMEOUT.
  3. The load balancer still considers the endpoint to beUNHEALTHYbecause the detailedTIMEOUT state maps to the basicUNHEALTHY state.

The following table provides a definition of each health state.

Detailed health check stateMeaningBasic state
HEALTHYThe endpoint is reachable and conforms to the requirements defined by the health check.HEALTHY
UNHEALTHYThe endpoint is reachable but does not conform to the requirements defined by the health check.UNHEALTHY
DRAININGThe endpoint is being drained. The existing connections to the endpoint are allowed to complete, but the new ones are being refused. Endpoint is consideredHEALTHY.HEALTHY
TIMEOUTThe endpoint is unreachable. Depending on the health check type, either a connection to the endpoint cannot be established or the server did not respond within the specified timeout. Endpoint is consideredUNHEALTHY.UNHEALTHY
UNKNOWNThe health check system is aware of the endpoint, but its health is not known. Endpoint is consideredUNHEALTHY.UNHEALTHY

There are multiple health checkers probing each endpoint; Google Cloudde-duplicates the log entries before logging so that only unique logs aregenerated.

If a health checker restarts, you might occasionally see the logged health statechange fromUNKNOWN to one of the known states listed earlier even though theendpoint's health state has not actually changed. Google Cloud usesbest-effort heuristics to suppress such log entries.

If you are usingconnection draining, thenhealth check logs arenot be generated with the endpoint health statusDRAINING. This is because health check logs reflect the results observed bythe health check probes, and connection draining does not impact the resultsobserved by the health check probe. Connection draining works by just informingthe load balancer that the new state isDRAINING, and it effectively overridesthe true health state of the endpoint as observed by the health checker.

You can interact with the logs by using the Cloud Logging API. The APIprovides ways to interactively filter logs that have specific fields set andexport matching logs to Cloud Logging, Cloud Storage, BigQuery,or Pub/Sub. For more information about the Cloud Logging API,seeCloud Logging API overview.

Health check log entry

TheLogEntryjsonPayload is populated with a fieldhealthCheckProbeResult that containsthe following information.

FieldTypeDescription
ipAddressstringThe primary internal IP address associated with the primary network interface of each backend VM. This is a human-readable string.
healthCheckProtocolenum(HealthCheckProtocol)The health check protocol used for health checking the endpoint. Examples: TCP, HTTP, HTTPS.
healthStateenum(HealthState)Current health status of the endpoint:HEALTHY orUNHEALTHY.
previousHealthStateenum(HealthState)The previous health status of the endpoint:HEALTHY orUNHEALTHY.
detailedHealthStateenum(DetailedHealthState)Current detailed health status of the endpoint. For a list of possibilities, seeHealth check states.

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

previousDetailedHealthStateenum(DetailedHealthState)The previous detailed health status of the endpoint. For a list of possibilities, seeHealth check states.

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

probeRequeststring

For HTTP, HTTPS, and HTTP/2, this is the URL request path (requestPath field in the resource config).

For TCP/SSL, this is the configured optional string that is sent after the health check connection is established (request field in the resource config).

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

probeCompletionTimestampgoogle.protobuf.TimestampProbe completion timestamp.
connectLatencygoogle.protobuf.DurationTime spent on setting up the connection for connection-oriented health check protocols TCP, SSL, HTTP, HTTPS, and HTTP/2.

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

responseLatencygoogle.protobuf.DurationLatency between request and response, as measured by the prober.

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

probeResultTextstringDescriptive text related to the probe result. It might say something like "Connection timed out" or "HTTP response: Bad Gateway", or it could be empty.

Not supported for distributed Envoy health checks for hybrid NEGs and regional internet NEGs.

probeSourceIpstringThe IP address from which the health check probe was sent.

For distributed Envoy health checks, this corresponds to the proxy IP address from the proxy-only subnet.

probeSourceRegionstring

The cloud vantage point region from which the health check originated.

This field is populated only for probes of Cloud DNS routing policies if thesourceRegions field is set in the corresponding health check.

targetIpstringThe IP address that is the target of the probe. This can be different thanipAddress. The destination IP address of the probe depends on the type of load balancer. For details, see Destination for probe packets in the Health checks overview.
targetPortintThe port that was the target of the probe. This can be the default port of the probe or the port that you specified when you created the health check.

Example filters

This section provides examples of common log filters.

Find all health check results for a particular instance group

logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"  ANDresource.type="gce_instance_group" ANDresource.labels.instance_group_name="INSTANCE_GROUP_NAME"

Find all health check results for a particular NEG

logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"  ANDresource.type="gce_network_endpoint_group" ANDresource.labels.network_endpoint_group_id="ENDPOINT_GROUP_ID"

Find all health check transitions for backend instance IP address10.128.15.201

logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"jsonPayload.healthCheckProbeResult.ipAddress="10.128.15.201"

Find all endpoints that were previously HEALTHY but now TIMEOUT

logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"jsonPayload.healthCheckProbeResult.previousDetailedHealthState="HEALTHY"jsonPayload.healthCheckProbeResult.detailedHealthState="TIMEOUT"

Find health logs from a specific time range

logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"timestamp>"2019-02-14T02:20:00.0Z"timestamp<"2019-02-14T03:30:00.0Z"

Limitations

  • Logs are generated for endpoint health transition only.
  • Legacy health checks are not supported.
  • Target pools are not supported.
  • Logs are not generated when the endpoint's health state isUNKNOWN.
  • In case of VM migrations, you might not see any log entries generated whenthe endpoint's health transitions to theUNHEALTHY state.
  • Logs are not generated when endpoints are deleted. For example, when youstop a VM.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-18 UTC.