Error guide
405 Method Not Allowed
A 405 Method Not Allowed error means the URL exists but does not accept the HTTP method used, commonly a GET sent to an endpoint built for POST.
A 405 Method Not Allowed error means the server found the resource at that URL but does not accept the HTTP method the request used. It is a more specific answer than a 404: the server is confirming the path is real and refusing the verb. RFC 9110, section 15.5.6, says the origin server MUST send an Allow header with a 405, listing the methods the resource does accept, so the fix is usually written on the response itself.
That is what separates it from the codes it gets confused with. A 404 means the server has no current representation at that URL, or will not disclose that it has one. A 403 means the server understood the request and refuses it, whatever the method, and a server may send a 404 instead to hide the resource. A 501 means the server does not support the method for any resource at all, where a 405 is about this one resource.
In monitoring, a 405 is one of the most common self-inflicted failures. Uptime checks default to GET, and plenty of API endpoints accept only POST, so pointing a default check at one produces a permanent 405 that says nothing about the service's health. Infrastructure causes it too, more often than people expect: a static file server rejecting POST, a proxy set to pass only some methods, or a CDN blocking anything that is not GET or HEAD.
| Code | What the server is saying | Where to look first |
|---|---|---|
| 405 Method Not Allowed | The URL exists, but not for this method. The Allow header lists the methods that work. | The method the client sent, and the Allow header |
| 404 Not Found | Nothing is at this URL, or the server will not say whether anything is. | The path, and the route it should match |
| 403 Forbidden | The request was understood and refused, whatever the method. | Permissions, credentials, and firewall or bot rules |
| 501 Not Implemented | The server does not support this method for any resource. | The server or proxy, which does not know the method at all |
Common causes
- A check or client using GET against an endpoint that only accepts POST, PUT or DELETE.
- A route defined for one method while the client uses another.
- A web server or CDN rule permitting only a subset of methods.
- A CORS preflight OPTIONS request reaching a route that does not handle OPTIONS.
- HEAD requests failing where GET succeeds, because the framework routes them separately.
How to diagnose it
- Read the Allow header on the response. It lists exactly which methods the resource accepts, and an empty Allow means it accepts none right now (RFC 9110, section 10.2.1).
- Confirm which method the client actually sent. On a 301 or 302 redirect, a client may turn a POST into a GET (RFC 9110, sections 15.4.2 and 15.4.3).
- Check the route definition for the method as well as the path.
- If OPTIONS is failing, look at CORS handling: preflight requests are a separate route in many frameworks.
- Test the same method one hop closer to the application to find out whether a proxy or the app is refusing it.
- If a fix does not seem to take, purge caches. A 405 is cacheable by default, so a CDN or browser may keep serving an old one.
Whose fault is it? Usually the client's side
The request used the wrong verb. The exception is a proxy or CDN that strips methods your application does support, which is a server-side configuration issue that presents identically.
What monitoring sees
A 405 falls outside the 200 to 399 range an Uptimely check accepts by default, so the check fails and the 405 is recorded with it. Website monitors always send a plain GET. API monitors send the method you choose, GET, POST, PUT, DELETE, PATCH or HEAD, with the headers and body you set, so a POST-only endpoint can be checked with a real POST. A 405 is an answer from the server, so it is not retried inside the check the way a connection error is. A failure that would make the monitor's status worse is still checked a second time before it counts, and by default an incident is declared only after two failed checks in a row.
Uptimely API monitors send the method, headers and body you choose, so a POST-only endpoint is checked with a real POST instead of failing with a 405.
Start monitoring free →Related error guides
Terms used on this page
Questions
What does 405 Method Not Allowed mean?
It means the server found the resource at that URL but will not accept the HTTP method the request used, such as a POST to a page that only takes GET. The server must say which methods it does accept, in an Allow header on the response.
How do I fix a 405 Method Not Allowed error?
Read the Allow header on the response and send one of the methods it lists. If the method should be allowed, check the route definition in the application, then any proxy, web server or CDN rule in front of it that limits methods.
What is the difference between a 405 and a 404?
A 404 says the server has nothing at that URL, or will not say whether it does. A 405 says the URL exists and only the method is wrong. So a 405 is the closer miss: change the method, not the address.
Why does my API monitor return 405?
Almost always because the check is sending GET to an endpoint that only accepts POST. In Uptimely, use an API monitor rather than a Website monitor, and set the method the endpoint expects along with any body and content-type header it needs.
Why does a POST request return 405 after a redirect?
Because the client may have switched to GET when it followed the redirect. RFC 9110 lets a client change POST to GET on a 301 or 302, and many do, so the request that reaches the new URL is a GET. Call the final URL directly, or redirect with a 307 or 308, which keep the method.
One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.