HTTP status codes / 501
501 Not Implemented — HTTP Status Code
A 501 Not Implemented response means the server does not support what the request asks for, most often an HTTP method it does not recognize at all. It differs from 405, which means the method is known but not allowed on that URL. A 501 is a statement about the server's capabilities, not a temporary failure.
What 501 means
501 Not Implemented means "I do not support the functionality needed to fulfill this request." It is defined in RFC 9110, Section 15.6.2, which names one case explicitly: the server does not recognize the request method and cannot support it for any resource. Section 9.1 of the same RFC backs this up, saying a server that receives an unrecognized or unimplemented method should respond with 501.
Although 501 is in the 5xx class, it is not a crash. It is the server stating a limit of its implementation. RFC 9110 also makes 501 heuristically cacheable, which reflects that the answer is not expected to change from one request to the next.
When you see it
- Unusual methods. A client sends
PROPFIND,PURGE,PATCHor a custom method to a server that has no handler for it. - Unsupported transfer codings. RFC 9112 says a server that receives a
Transfer-Encodingit does not understand should respond with 501. - Placeholder endpoints. Some APIs and frameworks return 501 from routes that are declared but not yet built.
- Gateways and API managers configured with a narrow set of methods, which answer anything else with 501.
501 vs 405
The two are easy to confuse:
| 405 Method Not Allowed | 501 Not Implemented | |
|---|---|---|
| Does the server know the method? | Yes | No, or cannot support it |
| Scope | This URL only | The whole server |
| Required header | Allow, listing accepted methods |
None |
| Typical fix | Use a method the URL accepts | Use a supported method or a different server |
A well-behaved server returns 405 when DELETE is valid elsewhere but not on this URL, and 501 when it has no idea what BREW is.
Common causes
- A client library or tool sending a method the server never implemented, such as
PATCHto an older application. - Cache purge tools sending
PURGEto an origin instead of to the cache that understands it. - WebDAV clients talking to a plain web server.
- A request with
Transfer-Encodingvalues the server cannot decode, sometimes added by a misbehaving proxy. - An API route that exists in the router but whose handler only throws "not implemented".
How to fix it
- Confirm the method. Check what your client actually sends; logs or
curl -vshow the request line. - Use a supported method. If the server supports
PUTbut notPATCH, change the client, or add the method to the server. - Send purge and WebDAV requests to the right component, such as your cache or a DAV-enabled server, not the general web server.
- Remove odd transfer codings added by intermediaries, or let the client use plain
Content-Length. - If you own the API, implement the handler, or return 405 with an
Allowheader if the method is simply not allowed on that route.
How to check it
Compare a normal method with an unknown one:
curl -s -o /dev/null -w "GET: %{http_code}\n" https://www.example.com/
curl -s -o /dev/null -w "BREW: %{http_code}\n" -X BREW https://www.example.com/
A server that answers BREW with 501 is following RFC 9110. If it answers 405, check the Allow header with curl -sI -X OPTIONS https://www.example.com/, where supported.
What it means for uptime monitoring
PingRobot's checker sends a GET with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and counts the final response as up only if its status is 200–399. A 501 counts as down, and the failure is confirmed from a second region before alerting.
Some tools check uptime with HEAD requests, and a server that does not implement HEAD may answer 501, which is a monitor configuration issue. Since PingRobot uses GET, which every general-purpose server must support, a 501 on a monitored URL deserves a closer look. It usually means the URL points at a stub or API route that does not handle GET, or a gateway in front of the app has been configured to reject it. If the URL used to return 200, treat it as a real regression, often from a deploy or gateway change.
Related codes
- 405 Method Not Allowed – the method is known but not allowed here.
- 505 HTTP Version Not Supported – the server rejects the protocol version.
- 500 Internal Server Error – an unexpected failure, not a missing feature.
- 502 Bad Gateway – an upstream gave an invalid response.
- 503 Service Unavailable – a temporary condition, unlike 501.
- 511 Network Authentication Required – another 5xx that does not mean the site failed.
Start monitoring free — 10 monitors, no credit card.
Frequently asked questions
What is the difference between 501 and 405?
A 405 means the server knows the method but this resource does not accept it, and it must list the allowed methods in an Allow header. A 501 means the server does not support the method anywhere, or lacks some other feature the request needs.
Is 501 a temporary error?
Usually not. It describes a missing capability, so retrying the same request will normally get the same answer. RFC 9110 even allows 501 responses to be cached heuristically.
Can a server return 501 for a GET request?
It should not for a normal resource, because RFC 9110 requires all general-purpose servers to support GET and HEAD. A 501 on GET usually points to a stub endpoint, a narrowly configured gateway or a proxy rejecting something else in the request.