HTTP Status Code Helper
Free HTTP Status Code Helper calculator with clear step-by-step results.
About HTTP Status Code Helper
Classifies a status code and answers the two operational questions that matter: whether a client should retry it, and whether it is cacheable without explicit headers. The volume figure converts an error rate into requests per minute, which is what makes an alert threshold meaningful.
Formulas
Status class
Class = floor(code / 100), giving 1xx through 5xx
Affected volume
Requests per minute = total RPM x error rate
Worked example
With the default values below, HTTP Status Code Helper returns Status class of 4xx Client error. Change any input above and every figure here is recalculated in your browser.
Inputs used
- HTTP status codeaccepts 100–599
- 429
- Requests per minute affectedminimum 0
- 1,200
- Share of requests returning this codeaccepts 0–100 %
- 4.5 %
Results
- Status class
- 4xx Client error
- Retry guidance
- Retry with exponential backoff and jitter
- Default cacheability
- Not cacheable by default
- Requests per minute returning this code
- 54.0
Step by step
- 1Values used
- 2Status class
- 3Affected volume
- 4Status class= 4xx Client error
- 5Retry guidance= Retry with exponential backoff and jitter
- 6Default cacheability= Not cacheable by default
- 7Requests per minute returning this code= 54.0
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Which codes are safe to retry?
408, 425, 429 and most 5xx responses, always with exponential backoff and jitter. 501 is not retryable because the server will never implement the method, and 4xx generally means the request itself is wrong.
Is 404 really cacheable?
Yes - 404 and 410 are cacheable by default under HTTP semantics, which surprises people debugging a resource that has since been created. Send explicit cache headers if that is not what you want.