Health checks in Nginx - Step-by-Step Execution

Process Flow - Health checks

Client sends request

↓

Nginx receives request

↓

Check backend server health

↓

Forward to

↓

Send response to client

Nginx receives a client request, checks if the backend server is healthy, then forwards the request or handles failure accordingly.

Execution Sample

Nginx

upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    health_check;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

This config sets up a backend with health checks and proxies client requests only to healthy servers.

Process Table

Step	Action	Health Check Result	Decision	Response
1	Client sends request	N/A	Nginx checks backend health	Waiting
2	Nginx performs health check	Backend is healthy	Forward request to backend	Waiting for backend response
3	Backend responds successfully	Healthy confirmed	Send backend response to client	200 OK with content
4	Next request arrives	Backend is unhealthy (3 fails)	Do not forward to backend	Return 502 Bad Gateway
5	Health check retries after fail_timeout	Backend recovers and is healthy	Forward request again	200 OK with content

💡 Execution stops after response is sent to client or error returned due to unhealthy backend.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5
backend_health	unknown	healthy	unhealthy	healthy
request_status	none	forwarded	blocked	forwarded
response_code	none	200	502	200

Key Moments - 2 Insights

Why does Nginx return 502 Bad Gateway sometimes even though the backend server exists?

Because the health check marked the backend as unhealthy after multiple failures (see execution_table step 4), so Nginx stops forwarding requests to it and returns an error.

How does Nginx decide when to retry sending requests to a previously unhealthy backend?

Nginx uses the fail_timeout setting to wait before retrying health checks (see execution_table step 5), and once the backend is healthy again, it resumes forwarding requests.

Visual Quiz - 3 Questions

Look at the execution table, what is the response code sent to the client at step 3?

A 200 OK

B 502 Bad Gateway

C 404 Not Found

D 500 Internal Server Error

💡 Hint

Check the 'Response' column in execution_table row for step 3.

At which step does Nginx decide not to forward the request due to backend health?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look for the step where 'Decision' is 'Do not forward to backend' in execution_table.

If the fail_timeout was increased, how would that affect the execution table?

A Step 3 would return 502 instead of 200

B Step 4 would be skipped

C Step 5 would occur later, delaying backend recovery

D Step 2 would never perform health checks

💡 Hint

Consider when health check retries happen in execution_table step 5.

Concept Snapshot

Nginx Health Checks:
- Use 'health_check;' inside upstream block
- Monitors backend server status
- Stops forwarding to unhealthy servers
- Returns error if no healthy backend
- Retries after fail_timeout period

Full Transcript

This visual execution shows how Nginx handles health checks for backend servers. When a client sends a request, Nginx first checks if the backend is healthy. If healthy, it forwards the request and returns the backend's response. If unhealthy, after multiple failures, Nginx returns an error like 502 Bad Gateway instead of forwarding. After waiting the fail_timeout period, Nginx retries health checks and resumes forwarding if the backend recovers. Variables like backend_health and response_code change accordingly during these steps.