Health checks configuration in GCP - Step-by-Step Execution

Process Flow - Health checks configuration

Start

↓

Define Health Check Parameters

↓

Create Health Check Resource

↓

Attach Health Check to Backend Service

↓

Health Check Runs Periodically

↓

Check Response Status

↓

Healthy?

Yes→Keep Backend Serving

No↓

Mark Backend as Unhealthy

↓

Stop Sending Traffic to Unhealthy Backend

↓

End

This flow shows how a health check is configured, attached, and used to monitor backend health, deciding traffic routing.

Execution Sample

GCP

gcloud compute health-checks create http my-health-check \
  --port 80 \
  --request-path /healthz \
  --check-interval 10s \
  --timeout 5s \
  --unhealthy-threshold 3 \
  --healthy-threshold 1

This command creates an HTTP health check that probes port 80 at path /healthz every 10 seconds, timing out after 5 seconds, marking unhealthy after 3 failures.

Process Table

Step	Action	Parameter/Value	Result/State
1	Define health check type	HTTP	Health check type set to HTTP
2	Set port	80	Health check will probe port 80
3	Set request path	/healthz	Health check requests /healthz path
4	Set check interval	10s	Health check runs every 10 seconds
5	Set timeout	5s	Health check waits 5 seconds for response
6	Set unhealthy threshold	3	Backend marked unhealthy after 3 failed checks
7	Create health check resource	my-health-check	Health check resource created
8	Attach to backend service	backend-service-1	Backend service linked to health check
9	Health check runs	First probe	Backend responds 200 OK, marked healthy
10	Health check runs	Second probe	Backend times out, failure count 1
11	Health check runs	Third probe	Backend times out, failure count 2
12	Health check runs	Fourth probe	Backend times out, failure count 3, marked unhealthy
13	Traffic routing	Backend unhealthy	Traffic stops routing to this backend
14	Health check runs	Backend recovers, responds 200 OK	Backend marked healthy again, traffic resumes

💡 Health check continuously runs; backend marked unhealthy after 3 failures and healthy after successful response.

Status Tracker

Variable	Start	After Step 9	After Step 12	After Step 14
failure_count	0	0	3	0
backend_health	unknown	healthy	unhealthy	healthy
traffic_routing	not set	routes to backend	stops routing	routes to backend

Key Moments - 3 Insights

Why does the backend only get marked unhealthy after 3 failed checks?

Because the unhealthy threshold is set to 3 (see execution_table step 6 and step 12), the system waits for 3 consecutive failures before marking unhealthy to avoid false positives.

What happens if the backend responds successfully after being unhealthy?

As shown in step 14, a successful response resets failure count and marks backend healthy again, resuming traffic routing.

Why is the timeout important in health checks?

Timeout (step 5) defines how long the check waits for a response; if exceeded, it counts as a failure, helping detect unresponsive backends.

Visual Quiz - 3 Questions

Look at the execution_table at which step does the backend become unhealthy?

A Step 12

B Step 10

C Step 9

D Step 14

💡 Hint

Check the 'Result/State' column in execution_table rows for failure count reaching 3.

According to variable_tracker, what is the failure_count after step 14?

A 3

B 0

C 1

D Unknown

💡 Hint

Look at the failure_count row in variable_tracker under 'After Step 14'.

If the check interval was changed from 10s to 5s, how would the execution_table change?

A Unhealthy threshold would change to 5

B Timeout would increase to 10s

C Health checks would run twice as often, steps 9-14 would happen faster

D Backend would never be marked unhealthy

💡 Hint

Check step 4 in execution_table about check interval and its effect on health check frequency.

Concept Snapshot

Health checks monitor backend health by sending requests at intervals.
Configure type, port, path, interval, timeout, and thresholds.
Failures count until unhealthy threshold marks backend unhealthy.
Healthy backends receive traffic; unhealthy ones do not.
Recovery happens when backend responds successfully again.

Full Transcript

Health checks configuration in GCP involves defining parameters like type (HTTP), port, request path, check interval, timeout, and unhealthy threshold. The health check resource is created and attached to a backend service. The health check runs periodically, sending requests to the backend. If the backend responds successfully, it is marked healthy and receives traffic. If it fails consecutively as per the unhealthy threshold, it is marked unhealthy and traffic stops routing to it. When the backend recovers and responds successfully, it is marked healthy again and traffic resumes. This process ensures only healthy backends serve traffic, improving reliability.

Practice

1.

What is the main purpose of a health check in Google Cloud Platform?

easy

A. To increase server storage capacity

B. To monitor if servers are working properly

C. To speed up network traffic

D. To backup data automatically

Solution

1. Step 1: Understand health check function

   Health checks regularly test if servers respond correctly to requests.

2. Step 2: Identify main purpose

   This helps detect unhealthy servers so they can be fixed or replaced.

3. Final Answer:

   To monitor if servers are working properly -> Option B

4. Quick Check:

   Health check = Monitor server health [OK]

Hint: Health checks watch server health, not storage or speed [OK]

Common Mistakes:

• Confusing health checks with backups
• Thinking health checks increase speed
• Assuming health checks add storage

2.

Which of the following is the correct way to specify a TCP health check in a Google Cloud load balancer configuration?

{
  "type": "TCP",
  "port": 80,
  "checkIntervalSec": 5
}

easy

A. { "type": "TCP", "port": 80, "checkIntervalSec": 5 }

B. { "type": "HTTP", "port": 80, "checkIntervalSec": 5 }

C. { "type": "UDP", "port": 80, "checkIntervalSec": 5 }

D. { "type": "ICMP", "port": 80, "checkIntervalSec": 5 }

Solution

1. Step 1: Identify correct health check type

   TCP health checks use "type": "TCP" to test TCP connections on the port.

2. Step 2: Match correct JSON syntax

   The example matches the correct syntax with type TCP, port 80, and interval 5 seconds.

3. Final Answer:

   { "type": "TCP", "port": 80, "checkIntervalSec": 5 } -> Option A

4. Quick Check:

   TCP type with port 80 = { "type": "TCP", "port": 80, "checkIntervalSec": 5 } [OK]

Hint: TCP health check uses type "TCP" exactly [OK]

Common Mistakes:

• Using HTTP instead of TCP for TCP check
• Using unsupported types like UDP or ICMP
• Wrong JSON syntax or missing fields

3.

Given this health check configuration snippet, what will happen if the server does not respond within 10 seconds?

{
  "type": "HTTP",
  "port": 8080,
  "timeoutSec": 10,
  "unhealthyThreshold": 3
}

medium

A. The server is marked unhealthy after 3 failed checks

B. The server is immediately removed after 1 failed check

C. The server is marked healthy regardless of response time

D. The server is restarted after 10 seconds

Solution

1. Step 1: Understand timeout and threshold

   The timeoutSec of 10 means the check waits 10 seconds for a response before failing.

2. Step 2: Apply unhealthyThreshold logic

   The server must fail 3 consecutive checks to be marked unhealthy.

3. Final Answer:

   The server is marked unhealthy after 3 failed checks -> Option A

4. Quick Check:

   Timeout + 3 failures = unhealthy after 3 tries [OK]

Hint: Unhealthy threshold counts failures before marking unhealthy [OK]

Common Mistakes:

• Thinking server is removed immediately after 1 failure
• Ignoring unhealthyThreshold setting
• Assuming server restarts automatically

4.

Identify the error in this health check configuration snippet:

{
  "type": "HTTP",
  "port": "eighty",
  "requestPath": "/health",
  "checkIntervalSec": 5
}

medium

A. checkIntervalSec must be at least 10 seconds

B. requestPath cannot be used with HTTP type

C. Port must be a number, not a string

D. type "HTTP" is invalid

Solution

1. Step 1: Check port field type

   The port value is "eighty" as a string, but it must be a numeric value like 80.

2. Step 2: Validate other fields

   requestPath is valid for HTTP, checkIntervalSec can be 5, and type "HTTP" is correct.

3. Final Answer:

   Port must be a number, not a string -> Option C

4. Quick Check:

   Port number must be numeric [OK]

Hint: Port must be a number, not words [OK]

Common Mistakes:

• Using string instead of number for port
• Thinking requestPath is invalid for HTTP
• Assuming checkIntervalSec minimum is 10

5.

You want to configure a health check that verifies your web app responds with HTTP 200 on path /status every 15 seconds, and marks the server unhealthy after 2 failures. Which configuration is correct?

hard

A. { "type": "HTTP", "port": 8080, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

B. { "type": "TCP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

C. { "type": "HTTP", "port": 80, "requestPath": "/health", "checkIntervalSec": 10, "unhealthyThreshold": 3 }

D. { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

Solution

1. Step 1: Match health check type and path

   The app uses HTTP checks on path "/status" so type must be "HTTP" and requestPath "/status".

2. Step 2: Verify timing and thresholds

   Check interval is 15 seconds and unhealthyThreshold is 2, matching requirements.

3. Step 3: Confirm port number

   Port 80 is standard for HTTP, so it fits the web app default.

4. Final Answer:

   { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 } -> Option D

5. Quick Check:

   HTTP + /status + 15s + 2 failures = { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 } [OK]

Hint: Match type, path, interval, and threshold exactly [OK]

Common Mistakes:

• Using TCP type for HTTP path
• Wrong requestPath or port
• Incorrect checkIntervalSec or unhealthyThreshold