Max fails and fail timeout in Nginx - Step-by-Step Execution

Process Flow - Max fails and fail timeout

Start request to backend

↓

Request success?

↓

Reset fail count

↓

Fail count >= max_fails?

No→Continue sending requests

Yes↓

Mark backend as down

↓

Wait fail_timeout seconds

↓

Retry backend

↓

If success, mark backend up and reset fail count

↓

Repeat process

This flow shows how nginx tracks failed requests to a backend server, marks it down after max fails, waits fail_timeout seconds, then retries.

Execution Sample

Nginx

upstream backend {
  server backend1.example.com max_fails=3 fail_timeout=10s;
}

proxy_pass http://backend;

Configures nginx to mark backend1 down after 3 failed requests within 10 seconds fail timeout.

Process Table

Step	Request Number	Request Result	Fail Count	Backend Status	Action
1	1	Success	0	Up	Reset fail count to 0, send next request
2	2	Fail	1	Up	Increment fail count to 1, send next request
3	3	Fail	2	Up	Increment fail count to 2, send next request
4	4	Fail	3	Down	Increment fail count to 3, mark backend Down
5	5	Request blocked	3	Down	Do not send request, wait fail_timeout
6	6	Retry after timeout	3	Down	Retry backend after 10s timeout
7	7	Success	0	Up	Reset fail count, mark backend Up, continue requests

💡 Backend marked down after 3 fails; after 10s fail_timeout, backend retried and marked up on success.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	Final
Fail Count	0	0	1	2	3	3	3	0
Backend Status	Up	Up	Up	Up	Down	Down	Down	Up

Key Moments - 3 Insights

Why does nginx stop sending requests after max_fails is reached?

Because once fail count reaches max_fails (row 4), nginx marks backend as Down and blocks further requests until fail_timeout passes (row 5).

What happens to fail count after a successful retry?

After a successful retry (row 7), nginx resets fail count to 0 and marks backend Up to resume normal requests.

Does fail_timeout start counting after the first failure or after max_fails?

fail_timeout countdown starts after max_fails is reached and backend is marked Down (row 4 to 5).

Visual Quiz - 3 Questions

Look at the execution table, what is the fail count at request number 3?

A 1

B 2

C 3

D 0

💡 Hint

Check the Fail Count column at Step 3 in the execution_table.

At which request number does nginx mark the backend as Down?

A Request 2

B Request 3

C Request 4

D Request 5

💡 Hint

Look at Backend Status and Action columns in execution_table rows.

If fail_timeout was increased to 20s, how would the execution table change?

A The backend would be retried after 20s instead of 10s at step 6

B Fail count would reset earlier

C Backend would never be marked Down

D Fail count would increment faster

💡 Hint

Refer to the Action column at Step 6 about retry timing.

Concept Snapshot

nginx max_fails and fail_timeout:
- max_fails: number of failed requests before marking backend down
- fail_timeout: time to wait before retrying backend
- After max_fails fails, backend marked Down
- Requests blocked during fail_timeout
- After timeout, backend retried and marked Up on success

Full Transcript

This visual execution trace shows how nginx uses max_fails and fail_timeout to manage backend server health. Each request increments fail count on failure. When fail count reaches max_fails, nginx marks the backend as down and stops sending requests. It waits fail_timeout seconds before retrying. If retry succeeds, fail count resets and backend is marked up again. This prevents sending requests to failing servers and improves reliability.