HTTP Status Codes

Nothing leaves your browser

Look up any HTTP status code, from 100 to 527, and find out what it means and what to do about it. Not sure which code to return? Ask the helper.

All HTTP status codes with what they mean, when they appear and what to do. The text follows the HTTP specification (RFC 9110 and related RFCs) and the MDN Web Docs, which every code links to; 418, 499 and Cloudflare's 520-527 are marked unofficial. Everything is on this page: nothing is fetched.

Search by code or word

Which code should I return?

What happened?

71 status codes.

All status codes

100ContinueThe server has the request headers and the client may go on and send the body.
When it is sent
The client sent Expect: 100-continue and the headers were acceptable.
What a client should do
Send the request body. If the body was already sent, ignore this response.
What a server should do
Answer quickly, after checking the headers, so large uploads are not sent in vain; send the final status after the body arrives.
Related headers
- Expect: 100-continue (request)
Typical causes
- A large upload where the client asked for permission first
Defined in: RFC 9110.MDN Web Docs Link to 100
101Switching ProtocolsThe server agrees to change the protocol of this connection.
When it is sent
The client sent an Upgrade header, most often to open a WebSocket.
What a client should do
Start speaking the new protocol on the same connection.
What a server should do
Send Upgrade and Connection: Upgrade headers naming the protocol you switch to.
Related headers
- Upgrade: the protocol switched to
- Connection: Upgrade
Typical causes
- WebSocket handshake
- HTTP/2 over cleartext (h2c) upgrade
Defined in: RFC 9110.MDN Web Docs Link to 101
102ProcessingObsoleteThe server is still working on a long request and has no answer yet.
When it is sent
A WebDAV request that takes a long time, so the client does not time out.
What a client should do
Keep waiting for the final response.
What a server should do
Rarely needed today; the code is obsolete in the newest WebDAV specification.
Typical causes
- Long WebDAV operations such as copying a big folder
Defined in: WebDAV, RFC 4918.MDN Web Docs Link to 102
103Early HintsThe server sends hints about resources to preload while it prepares the real response.
When it is sent
The server knows which scripts and styles the page will need before the page itself is ready.
What a client should do
Start preloading the linked resources; wait for the final response as usual.
What a server should do
Send Link headers with rel=preload or preconnect, then the final status. Not every client uses the hints.
Related headers
- Link: resources to preload or preconnect to
Typical causes
- A slow page that sends the hints while the server builds the HTML
Defined in: RFC 8297.MDN Web Docs Link to 103
200OKThe request succeeded.
When it is sent
A normal successful GET, POST (with a result in the body), PUT or PATCH.
What a client should do
Use the response body; for GET it holds the resource.
What a server should do
Return the data in the body. If there is nothing to return use 204; if you created something use 201.
Related headers
- Content-Type: format of the body
- ETag, Last-Modified: for caching
Typical causes
- Any ordinary successful request
Defined in: RFC 9110.MDN Web Docs Link to 200
201CreatedThe request succeeded and a new resource was created.
When it is sent
A POST or PUT that made a new resource.
What a client should do
Read the Location header to find the new resource.
What a server should do
Put the new resource's address in Location and, when it is cheap, a representation of it in the body.
Related headers
- Location: address of the new resource
- ETag: version of the new resource
Typical causes
- Creating a user, an order or a file through an API
Defined in: RFC 9110.MDN Web Docs Link to 201
202AcceptedThe request was taken in but is not finished: it will be processed later.
When it is sent
Work is queued or runs in the background, and the result is not known yet.
What a client should do
Do not assume it worked. Poll the status address or wait for a callback.
What a server should do
Tell the client where to follow progress (a status URL in Location or the body). Do not use it when the work is already done.
Related headers
- Location: where to check the status
- Retry-After: when to look again
Typical causes
- Batch jobs, video processing, email sending
Defined in: RFC 9110.MDN Web Docs Link to 202
203Non-Authoritative InformationThe response is the origin's, but a proxy changed it on the way.
When it is sent
A transforming proxy altered the response.
What a client should do
Treat the content as probably right but possibly modified.
What a server should do
Rarely sent on purpose; it is a proxy's marker.
Typical causes
- A proxy that rewrites content (ad removal, compression)
Defined in: RFC 9110.MDN Web Docs Link to 203
204No ContentThe request succeeded and there is nothing to send back.
When it is sent
A DELETE, or a PUT or PATCH where the client already has the data; also OPTIONS and CORS preflight answers.
What a client should do
Do not expect a body. Keep the current page or form as it is.
What a server should do
Send no body and no Content-Length other than 0. Good for a successful delete.
Typical causes
- A successful DELETE
- A save that returns nothing
- CORS preflight (OPTIONS) answers
Defined in: RFC 9110.MDN Web Docs Link to 204
205Reset ContentThe request succeeded; the client should clear the form or view it came from.
When it is sent
A form was submitted and should be emptied for the next entry.
What a client should do
Reset the document view (for example clear the form).
What a server should do
Send no body. Support in clients is uneven, so 204 is safer.
Typical causes
- Data-entry forms that expect repeated submissions
Defined in: RFC 9110.MDN Web Docs Link to 205
206Partial ContentThe server is sending only the part of the resource that was asked for.
When it is sent
A request with a Range header (resumed downloads, video seeking).
What a client should do
Put the parts together using Content-Range; keep the rest for later.
What a server should do
Honour Range, send Content-Range and the right Content-Length; advertise support with Accept-Ranges: bytes.
Related headers
- Content-Range: which bytes are sent
- Accept-Ranges: bytes
- Range (request)
Typical causes
- Resumed downloads
- Video and audio seeking
- PDF viewers loading pages
Defined in: RFC 9110.MDN Web Docs Link to 206
207Multi-StatusThe body holds separate results for several operations.
When it is sent
A WebDAV request that touched many resources, each with its own outcome.
What a client should do
Read the XML body; each part has its own status.
What a server should do
Return an XML multistatus body, one status per resource.
Typical causes
- Bulk WebDAV operations
Defined in: WebDAV, RFC 4918.MDN Web Docs Link to 207
208Already ReportedThe members of a WebDAV binding were already listed earlier in this response.
When it is sent
A WebDAV listing that would repeat the same members.
What a client should do
Skip the repeated members.
What a server should do
Used inside a 207 body to avoid listing the same resource twice.
Typical causes
- WebDAV bindings
Defined in: RFC 5842.MDN Web Docs Link to 208
226IM UsedThe response is the result of applying one or more instance manipulations (such as a delta) to the resource.
When it is sent
A client asked for a delta with A-IM and the server used it.
What a client should do
Apply the delta to the copy you have.
What a server should do
Rarely used; part of delta encoding for HTTP.
Related headers
- IM: manipulations used
- A-IM (request)
Typical causes
- Delta encoding
Defined in: RFC 3229.MDN Web Docs Link to 226
300Multiple ChoicesThe resource has several representations; the client may choose one.
When it is sent
The server offers several choices and has no preferred one.
What a client should do
Pick one of the listed alternatives, or follow Location if the server named a preferred one.
What a server should do
Rarely used: negotiate content with Accept headers or redirect to one address instead.
Related headers
- Location: the preferred choice, if any
Typical causes
- Servers that list several formats or languages
Defined in: RFC 9110.MDN Web Docs Link to 300
301Moved PermanentlyThe resource now lives at a new address, for good.
When it is sent
A page was moved or renamed, or the site switched to https or a new domain.
What a client should do
Use the new address from now on; browsers and search engines remember it. A POST may be turned into a GET: use 308 when the method must stay.
What a server should do
Send the new address in Location. Because it is cached hard, only use it when you will never go back.
Related headers
- Location: the new address
- Cache-Control: how long to remember
Typical causes
- Domain or URL changes
- http to https
- Trailing slash redirects
Defined in: RFC 9110.MDN Web Docs Link to 301
302FoundThe resource is temporarily at another address.
When it is sent
A temporary move, a login redirect, or a one-off redirect.
What a client should do
Follow Location this time but keep using the original address next time. Old clients may change POST into GET.
What a server should do
Use 307 to keep the method or 303 to ask for a GET. Do not use it for permanent moves (search engines keep the old address).
Related headers
- Location: the temporary address
Typical causes
- Redirect to a login page
- Temporary maintenance page
- A/B test redirects
Defined in: RFC 9110.MDN Web Docs Link to 302
303See OtherThe result is at another address, which must be fetched with GET.
When it is sent
After a POST, PUT or DELETE, to send the client to a result page (Post/Redirect/Get).
What a client should do
Request Location with GET, whatever the first method was.
What a server should do
Use it after a form submission so that a page refresh does not send the form again.
Related headers
- Location: where the result is
Typical causes
- Post/Redirect/Get after a form
- Redirect to a status resource
Defined in: RFC 9110.MDN Web Docs Link to 303
304Not ModifiedThe cached copy is still good; no body is sent.
When it is sent
A conditional GET (If-None-Match or If-Modified-Since) found nothing changed.
What a client should do
Use your cached copy.
What a server should do
Send no body. Include the same ETag, Cache-Control and Vary headers a 200 would carry.
Related headers
- ETag, Last-Modified: validators
- Cache-Control, Expires, Vary
- If-None-Match, If-Modified-Since (request)
Typical causes
- Browser revalidating cached files
- CDN and proxy revalidation
Defined in: RFC 9110.MDN Web Docs Link to 304
305Use ProxyObsoleteThe resource must be reached through the proxy given in Location.
When it is sent
Defined in early HTTP; no longer used.
What a client should do
Do not rely on it; browsers ignore it for security reasons.
What a server should do
Do not send it.
Related headers
- Location: the proxy
Typical causes
- Historical
Defined in: RFC 9110.MDN Web Docs Link to 305
307Temporary RedirectThe resource is temporarily at another address, and the method and body must stay the same.
When it is sent
A temporary move where a POST must stay a POST.
What a client should do
Repeat the same request, with the same method and body, at Location.
What a server should do
Prefer it to 302 when the method matters. The original address stays valid.
Related headers
- Location: the temporary address
Typical causes
- API endpoints being moved temporarily
- HSTS internal redirects in browsers
Defined in: RFC 9110.MDN Web Docs Link to 307
308Permanent RedirectThe resource moved for good, and the method and body must stay the same.
When it is sent
A permanent move where a POST must stay a POST.
What a client should do
Use the new address from now on, with the same method.
What a server should do
The permanent counterpart of 307. Search engines treat it like 301.
Related headers
- Location: the new address
Typical causes
- Moving an API endpoint permanently
Defined in: RFC 9110.MDN Web Docs Link to 308
400Bad RequestThe server cannot understand the request because it is malformed.
When it is sent
Invalid syntax: broken JSON, a bad header, a request that is too confusing to parse.
What a client should do
Do not repeat it unchanged. Fix the request first.
What a server should do
Say what is wrong in the body (a field name and a message). For well-formed data that breaks a rule, 422 is more precise.
Typical causes
- Invalid JSON
- Missing required parameter
- Malformed cookie or header
- A request body that does not match Content-Type
Defined in: RFC 9110.MDN Web Docs Link to 400
401UnauthorizedThe request has no valid credentials: the client is not authenticated.
When it is sent
No login, a wrong password, or an expired or invalid token.
What a client should do
Log in or get a new token, then repeat the request.
What a server should do
Send WWW-Authenticate naming the scheme. Despite its name it is about who you are, not what you may do: use 403 for that.
Related headers
- WWW-Authenticate: how to authenticate (Bearer, Basic...)
Typical causes
- Missing Authorization header
- Expired or revoked token
- Wrong API key
Defined in: RFC 9110.MDN Web Docs Link to 401
402Payment RequiredReserved for digital payment; there is no standard use.
When it is sent
Some APIs use it for billing problems or exhausted quotas.
What a client should do
Check the provider's documentation for what it means there.
What a server should do
Avoid it unless you document it. 403 or 429 are usually clearer.
Typical causes
- Unpaid subscription
- Plan limit reached on some APIs
Defined in: RFC 9110.MDN Web Docs Link to 402
403ForbiddenThe server understood the request but refuses to allow it: the client is known, but not permitted.
When it is sent
The user is logged in but lacks the right, or the address is blocked.
What a client should do
Do not retry with the same credentials; ask for access or use another account.
What a server should do
Use it for missing permission. To hide that a resource exists from people who may not see it, 404 can be used instead.
Typical causes
- Missing role or permission
- IP or region blocked
- CSRF check failed
- Directory listing disabled
Defined in: RFC 9110.MDN Web Docs Link to 403
404Not FoundThe server cannot find the requested resource.
When it is sent
The address does not exist, or the server will not say that it does.
What a client should do
Check the address. The resource may exist later; it is not said to be gone for good.
What a server should do
Use 410 when something was removed on purpose. Return a helpful page, and use 404 to hide private resources.
Typical causes
- Typo in the URL
- Deleted or renamed content
- Wrong base path or route
- Missing static file
Defined in: RFC 9110.MDN Web Docs Link to 404
405Method Not AllowedThe address exists, but not for this HTTP method.
When it is sent
A POST to a read-only address, or a GET to an endpoint that only accepts POST.
What a client should do
Use one of the methods listed in Allow.
What a server should do
Always send the Allow header with the permitted methods.
Related headers
- Allow: the methods the resource supports
Typical causes
- Wrong method in an API call
- CORS preflight sent to a route without OPTIONS
Defined in: RFC 9110.MDN Web Docs Link to 405
406Not AcceptableThe server cannot produce a response matching the Accept headers.
When it is sent
The client asked for a format, language or encoding the server does not have.
What a client should do
Change the Accept, Accept-Language or Accept-Encoding headers.
What a server should do
List the available formats in the body. Many servers ignore Accept and send a default instead.
Related headers
- Accept, Accept-Language, Accept-Encoding (request)
Typical causes
- Asking for XML from a JSON-only API
Defined in: RFC 9110.MDN Web Docs Link to 406
407Proxy Authentication RequiredA proxy between the client and the server wants credentials first.
When it is sent
A corporate or authenticating proxy needs a login.
What a client should do
Send Proxy-Authorization with valid credentials.
What a server should do
Proxies send Proxy-Authenticate naming the scheme.
Related headers
- Proxy-Authenticate: scheme the proxy accepts
- Proxy-Authorization (request)
Typical causes
- Corporate proxy
Defined in: RFC 9110.MDN Web Docs Link to 407
408Request TimeoutThe server gave up waiting for the client to finish sending the request.
When it is sent
The connection was idle, or the request arrived too slowly.
What a client should do
Repeat the request, possibly on a new connection.
What a server should do
Send Connection: close. Do not set the wait too short for slow mobile networks.
Related headers
- Connection: close
Typical causes
- Slow or dropped network
- A client that opened a connection and sent nothing
Defined in: RFC 9110.MDN Web Docs Link to 408
409ConflictThe request conflicts with the current state of the resource.
When it is sent
A duplicate (an email already registered), an edit made on an old version, or a state that does not allow the action.
What a client should do
Fetch the current state, resolve the conflict, then try again.
What a server should do
Explain the conflict in the body so the client can fix it. For stale edits, 412 with ETag is the more precise code.
Typical causes
- Duplicate unique value
- Concurrent edits
- Deleting a folder that is not empty
Defined in: RFC 9110.MDN Web Docs Link to 409
410GoneThe resource was removed on purpose and will not come back.
When it is sent
Content that was permanently deleted, with no new address.
What a client should do
Remove links and bookmarks to it; do not retry.
What a server should do
Use it instead of 404 when you know the removal is permanent; search engines drop the page faster.
Typical causes
- Expired offers
- Permanently deleted content
Defined in: RFC 9110.MDN Web Docs Link to 410
411Length RequiredThe server requires a Content-Length header.
When it is sent
The request had a body but no length.
What a client should do
Add the Content-Length header and send again.
What a server should do
Rare today, since chunked transfer covers unknown lengths.
Related headers
- Content-Length (request)
Typical causes
- Some servers that reject chunked uploads
Defined in: RFC 9110.MDN Web Docs Link to 411
412Precondition FailedA condition in the request headers was not true on the server.
When it is sent
If-Match or If-Unmodified-Since did not match: the resource changed since the client read it.
What a client should do
Fetch the current version, merge your changes, and send again with the new ETag.
What a server should do
Use it to prevent lost updates in PUT and PATCH (optimistic locking).
Related headers
- If-Match, If-Unmodified-Since (request)
- ETag: the current version
Typical causes
- Lost-update protection
- Another user changed the resource first
Defined in: RFC 9110.MDN Web Docs Link to 412
413Content Too LargeThe request body is larger than the server will accept.
When it is sent
An upload bigger than a configured limit.
What a client should do
Send less data, or split the upload.
What a server should do
Say the limit in the body. Reverse proxies often set their own, lower limit.
Related headers
- Retry-After: if the limit is temporary
Typical causes
- Upload over the limit (nginx client_max_body_size)
- A very large JSON body
Defined in: RFC 9110.MDN Web Docs Link to 413
414URI Too LongThe address of the request is longer than the server accepts.
When it is sent
A very long query string, or a redirect loop that keeps adding to the URL.
What a client should do
Shorten the address; send long data in a POST body.
What a server should do
Set a generous limit and log the cause: it is often a loop.
Typical causes
- Huge GET query
- Redirect loops adding parameters
Defined in: RFC 9110.MDN Web Docs Link to 414
415Unsupported Media TypeThe server does not accept the format of the request body.
When it is sent
The Content-Type is not supported, or does not match the body.
What a client should do
Send a supported Content-Type (often application/json).
What a server should do
List the accepted types in Accept or Accept-Post.
Related headers
- Content-Type (request)
- Accept, Accept-Post: formats the server accepts
Typical causes
- Sending form data to a JSON-only endpoint
- A missing Content-Type header
Defined in: RFC 9110.MDN Web Docs Link to 415
416Range Not SatisfiableThe requested byte range lies outside the resource.
When it is sent
A Range header that starts after the end of the file.
What a client should do
Ask without a range, or use the size in Content-Range to pick a valid one.
What a server should do
Send Content-Range: bytes */size.
Related headers
- Content-Range: bytes */size
Typical causes
- A resumed download of a file that changed or shrank
Defined in: RFC 9110.MDN Web Docs Link to 416
417Expectation FailedThe server cannot meet what the Expect header asked for.
When it is sent
An Expect value the server does not support.
What a client should do
Send the request without the Expect header.
What a server should do
Rare; often a proxy that does not handle Expect: 100-continue.
Related headers
- Expect (request)
Typical causes
- Old proxies
Defined in: RFC 9110.MDN Web Docs Link to 417
418I'm a teapotUnofficialA joke code from the 1998 Hyper Text Coffee Pot Control Protocol: the server is a teapot and refuses to brew coffee.
When it is sent
April Fools' RFC 2324; some services use it to mean "I will not do that" or to turn away bots.
What a client should do
Treat it as a refusal; do not retry.
What a server should do
Do not use it for real errors. HTTP's current specification only reserves the number.
Typical causes
- Easter eggs
- Bot blocking on some sites
Defined in: RFC 2324 (April Fools' joke).MDN Web Docs Link to 418
421Misdirected RequestThe request was sent to a server that cannot answer for this host.
When it is sent
HTTP/2 connection reuse across hosts that the server does not serve.
What a client should do
Open a new connection and repeat the request.
What a server should do
Return it when this connection is not the right one for the Host.
Typical causes
- HTTP/2 connection coalescing with wrong certificates
Defined in: RFC 9110.MDN Web Docs Link to 421
422Unprocessable ContentThe request is well-formed but breaks a rule, so it cannot be processed.
When it is sent
Validation failed: valid JSON, but a field is missing, out of range or inconsistent.
What a client should do
Read the error details, correct the data and send again.
What a server should do
List each field and its problem in the body. Use 400 when the request cannot even be parsed.
Typical causes
- Form or API validation errors
- A business rule violated
Defined in: RFC 9110.MDN Web Docs Link to 422
423LockedThe resource is locked.
When it is sent
A WebDAV resource that someone else has locked.
What a client should do
Wait, or use the lock token if you hold the lock.
What a server should do
Describe the lock in the body.
Typical causes
- WebDAV locks
Defined in: WebDAV, RFC 4918.MDN Web Docs Link to 423
424Failed DependencyThe request failed because an earlier request it depended on failed.
When it is sent
One step of a multi-part WebDAV operation failed.
What a client should do
Fix the request that failed first.
What a server should do
Used inside 207 responses.
Typical causes
- WebDAV batch operations
Defined in: WebDAV, RFC 4918.MDN Web Docs Link to 424
425Too EarlyThe server will not process a request that might be replayed.
When it is sent
A request sent in TLS 1.3 early data (0-RTT) that is not safe to repeat.
What a client should do
Repeat the request after the handshake finishes.
What a server should do
Return it for non-idempotent requests that arrive as early data.
Related headers
- Early-Data: 1 (set by a proxy)
Typical causes
- TLS 0-RTT
Defined in: RFC 8470.MDN Web Docs Link to 425
426Upgrade RequiredThe client must switch to another protocol to continue.
When it is sent
The server refuses this protocol version (for example plain HTTP/1.1 or TLS 1.0).
What a client should do
Switch to a protocol named in Upgrade and retry.
What a server should do
Send Upgrade and Connection: Upgrade.
Related headers
- Upgrade: the protocol(s) required
- Connection: Upgrade
Typical causes
- Server requires TLS or HTTP/2
- WebSocket-only endpoint
Defined in: RFC 9110.MDN Web Docs Link to 426
428Precondition RequiredThe server requires the request to be conditional.
When it is sent
A PUT or PATCH without If-Match, on a server that insists on it to avoid lost updates.
What a client should do
Read the resource first, then send it with If-Match.
What a server should do
Use it to enforce optimistic locking.
Related headers
- If-Match (request)
Typical causes
- APIs that require an ETag on updates
Defined in: RFC 6585.MDN Web Docs Link to 428
429Too Many RequestsThe client sent too many requests in a given time (rate limiting).
When it is sent
A per-user, per-IP or per-key limit was hit.
What a client should do
Slow down and wait for Retry-After before trying again; use exponential backoff.
What a server should do
Send Retry-After (seconds or a date) and, if you can, the remaining quota in RateLimit headers.
Related headers
- Retry-After: how long to wait
- RateLimit-*, X-RateLimit-*: quota information
Typical causes
- API quota exceeded
- Scraping or a retry storm
- Login attempts limit
Defined in: RFC 6585.MDN Web Docs Link to 429
431Request Header Fields Too LargeThe request headers, in total or one of them, are too big.
When it is sent
Giant cookies or an oversized Authorization header.
What a client should do
Reduce the headers; clear cookies.
What a server should do
Say which header is too large when you can.
Typical causes
- Too many or too large cookies
- A very large JWT
Defined in: RFC 6585.MDN Web Docs Link to 431
451Unavailable For Legal ReasonsThe resource is withheld for legal reasons.
When it is sent
A court order, censorship or regional law blocks the content.
What a client should do
Do not retry; the content is not available to you.
What a server should do
Name the party responsible in a Link header with rel="blocked-by".
Related headers
- Link: rel="blocked-by" naming who blocks it
Typical causes
- Court orders
- Geo-blocking for legal reasons
- Takedown requests
Defined in: RFC 7725.MDN Web Docs Link to 451
499Client Closed RequestUnofficialThe client closed the connection before the server answered. Used by nginx in its logs.
When it is sent
The user left, a request timed out on the client's side, or a load balancer gave up.
What a client should do
Nothing to read: the client is gone. Retry if the action matters, and check client timeouts.
What a server should do
Not a real response; it appears in nginx logs. A burst of 499s usually means slow responses.
Typical causes
- Client timeout shorter than the server's work
- Users navigating away
- Load balancer timeout
Defined in: nginx (not an official HTTP code).Link to 499
500Internal Server ErrorThe server hit an unexpected problem and could not complete the request.
When it is sent
A bug, an unhandled exception, or a broken configuration.
What a client should do
Try again later; if it keeps happening, report it. Do not change the request.
What a server should do
Log the cause and a request id, but do not leak stack traces to clients.
Typical causes
- An unhandled exception
- A failed database call
- Configuration error
- A crash in a script (PHP, CGI)
Defined in: RFC 9110.MDN Web Docs Link to 500
501Not ImplementedThe server does not support the functionality needed for this request.
When it is sent
An HTTP method or feature the server does not know.
What a client should do
Do not repeat it; use another method.
What a server should do
Use 405 when the method is known but not allowed here.
Related headers
- Retry-After: if the feature may come later
Typical causes
- An unknown HTTP method
- An endpoint that is only a stub
Defined in: RFC 9110.MDN Web Docs Link to 501
502Bad GatewayA gateway or proxy got an invalid response from the server behind it.
When it is sent
The upstream application crashed, returned garbage, or closed the connection.
What a client should do
Try again shortly; the fault is between servers, not in your request.
What a server should do
Look at the upstream's health and logs (the proxy only reports that the upstream misbehaved).
Typical causes
- The app server crashed or is restarting
- Wrong upstream port or address
- Upstream sent an invalid response
- A deploy in progress
Defined in: RFC 9110.MDN Web Docs Link to 502
503Service UnavailableThe server cannot handle the request right now: overloaded or down for maintenance.
When it is sent
Maintenance, overload, or an app that is starting up.
What a client should do
Wait and retry later, honouring Retry-After.
What a server should do
Send Retry-After. Use it deliberately for planned maintenance and load shedding.
Related headers
- Retry-After: when to try again
Typical causes
- Planned maintenance
- Overload or exhausted connection pool
- Deploy or restart in progress
Defined in: RFC 9110.MDN Web Docs Link to 503
504Gateway TimeoutA gateway or proxy did not get a response from the upstream server in time.
When it is sent
The upstream is too slow or unreachable.
What a client should do
Retry later. For slow operations, ask the server to run them in the background.
What a server should do
Raise the proxy timeout only if the work is legitimately long; otherwise make the work faster or asynchronous.
Typical causes
- A slow database query
- An upstream that hangs
- A proxy timeout shorter than the work
Defined in: RFC 9110.MDN Web Docs Link to 504
505HTTP Version Not SupportedThe server does not support the HTTP version of the request.
When it is sent
A very old or very new protocol version.
What a client should do
Use a version the server supports.
What a server should do
List supported versions in the body.
Typical causes
- Ancient HTTP/0.9 clients
- Misconfigured proxies
Defined in: RFC 9110.MDN Web Docs Link to 505
506Variant Also NegotiatesThe server has a configuration error in content negotiation.
When it is sent
A negotiation setup that refers to itself.
What a client should do
Nothing: this is a server configuration problem; report it.
What a server should do
Fix the negotiation configuration.
Typical causes
- Circular transparent content negotiation
Defined in: RFC 2295.MDN Web Docs Link to 506
507Insufficient StorageThe server cannot store what is needed to complete the request.
When it is sent
A WebDAV request when the disk or quota is full.
What a client should do
Free space or ask for more quota, then try again.
What a server should do
Treat it as temporary if space can be freed.
Typical causes
- A full disk or quota
Defined in: WebDAV, RFC 4918.MDN Web Docs Link to 507
508Loop DetectedThe server stopped because it found an infinite loop.
When it is sent
A WebDAV operation that follows links in a cycle.
What a client should do
Remove the cycle from the structure.
What a server should do
Return it instead of looping.
Typical causes
- Circular WebDAV bindings
Defined in: RFC 5842.MDN Web Docs Link to 508
510Not ExtendedObsoleteThe server needs further extensions to the request (an obsolete extension framework).
When it is sent
Defined for the HTTP Extension Framework; effectively unused.
What a client should do
Do not rely on it.
What a server should do
Do not send it.
Typical causes
- Historical
Defined in: RFC 2774.MDN Web Docs Link to 510
511Network Authentication RequiredThe client must log in to the network before it can reach the internet.
When it is sent
A captive portal (hotel, airport or café Wi-Fi) is intercepting traffic.
What a client should do
Open the portal's login page, then repeat the request.
What a server should do
Sent by the intercepting network, not by the website.
Typical causes
- Public Wi-Fi sign-in pages
Defined in: RFC 6585.MDN Web Docs Link to 511
520Web Server Returned an Unknown ErrorUnofficialCloudflare received a response from your origin that it could not understand.
When it is sent
The origin crashed, sent an empty or invalid response, or reset the connection.
What a client should do
Retry later; the problem is on the site's server.
What a server should do
Check the origin's logs, and that it sends valid HTTP with a sensible number and size of headers.
Typical causes
- Origin crash or reset
- Oversized or too many response headers
- Empty response from the origin
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 520
521Web Server Is DownUnofficialCloudflare could not connect to your origin server.
When it is sent
The origin refused the connection or is down.
What a client should do
Retry later.
What a server should do
Check that the origin is running and that its firewall allows Cloudflare's addresses.
Typical causes
- Origin offline
- Firewall blocking Cloudflare
- Wrong port
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 521
522Connection Timed OutUnofficialCloudflare timed out while connecting to your origin server.
When it is sent
The origin is overloaded or unreachable, so the TCP handshake did not finish.
What a client should do
Retry later.
What a server should do
Check the origin's load, network path and firewall; make sure Cloudflare's addresses are allowed.
Typical causes
- Overloaded origin
- Packet loss or firewall drops
- Wrong origin IP
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 522
523Origin Is UnreachableUnofficialCloudflare cannot reach your origin server.
When it is sent
A DNS or routing problem between Cloudflare and the origin.
What a client should do
Retry later.
What a server should do
Check the DNS records Cloudflare uses for the origin and the network route.
Typical causes
- Wrong or missing DNS record for the origin
- Routing problem
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 523
524A Timeout OccurredUnofficialCloudflare connected to your origin, but it did not answer in time.
When it is sent
A request that takes longer than about 100 seconds.
What a client should do
Retry later; long jobs need to be run in the background.
What a server should do
Make slow requests faster or asynchronous (return 202 and let the client poll).
Typical causes
- Slow queries or reports
- A hung application
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 524
525SSL Handshake FailedUnofficialCloudflare could not complete a TLS handshake with your origin.
When it is sent
The origin does not speak TLS correctly or offers incompatible settings.
What a client should do
Retry later; the site must fix its server.
What a server should do
Check that the origin serves HTTPS on the expected port with supported TLS versions and ciphers.
Typical causes
- TLS not enabled on the origin
- Unsupported cipher or protocol
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 525
526Invalid SSL CertificateUnofficialCloudflare could not validate the TLS certificate of your origin.
When it is sent
The origin's certificate is expired, self-signed or for another name, while Cloudflare is set to strict checking.
What a client should do
Retry later; the site must fix its certificate.
What a server should do
Install a valid certificate or use a Cloudflare Origin certificate.
Typical causes
- Expired or self-signed origin certificate
- Name mismatch
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 526
527Railgun ErrorObsoleteThe connection between Cloudflare and Railgun (a retired Cloudflare optimiser) failed.
When it is sent
Only seen on old setups that still used Railgun.
What a client should do
Retry later.
What a server should do
Railgun is no longer offered; remove it from the setup.
Typical causes
- Legacy Railgun configuration
Defined in: Cloudflare (not an official HTTP code).Cloudflare documentation Link to 527

Which code should I return?

All status codes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers

Typical causes

When it is sent

What a client should do

What a server should do

Related headers