# Not 404 but 405! The Web Analytics beacon just got more honest

Hey there, it's me, Shii-chan! Today I've got a tiny but delightfully correct update for you. Picking the right HTTP status code makes it so much easier to spot what went wrong.

## What was announced?

The `/cdn-cgi/rum` beacon endpoint used by [Cloudflare Web Analytics](https://developers.cloudflare.com/web-analytics/) has changed how it responds to non-POST requests. This was announced on Cloudflare's Changelog.

Until now it returned `404 Not Found`, but from here on it returns `405 Method Not Allowed`, and the response comes with an `Allow: POST, OPTIONS` header.

## The story so far

Previously, hitting the endpoint with a GET or some other unsupported HTTP method gave you a `404`. But that basically says "this endpoint doesn't exist," which is a bit misleading. The endpoint was there the whole time, so it was easy to wonder if something had gone missing.

## What changes

Now you get a `405`, which clearly says "the endpoint exists, but it doesn't accept that method." And the `Allow: POST, OPTIONS` header tells you right away, "send it with POST or OPTIONS and you're good." That's a friendly little win for anyone debugging.

## Dive Deep

The combination of `405` plus an `Allow` header is the correct behavior described in [RFC 9110 §15.5.6](https://www.rfc-editor.org/rfc/rfc9110#section-15.5.6). The RFC asks you to advertise the allowed methods via the `Allow` header when returning Method Not Allowed, and this change lines up neatly with that.

Your normal Web Analytics beacon operations aren't affected, so no worries there. The beacon (`beacon.min.js`) already sends all its metric submissions via POST. CORS preflight OPTIONS requests keep working exactly as before too.

If you spot a `405` and want to know more, there's an explanation in the [Web Analytics FAQ](https://developers.cloudflare.com/web-analytics/faq/#why-am-i-getting-a-405-method-not-allowed-error-from-cdn-cgirum).

## Wrap-up

- `/cdn-cgi/rum` now returns `405 Method Not Allowed` instead of `404` for non-POST requests
- The response carries an `Allow: POST, OPTIONS` header, making it RFC 9110 compliant
- Normal beacon metrics and CORS OPTIONS requests are unaffected

If you've ever squinted at your Web Analytics logs and puzzled over the `/cdn-cgi/rum` response, this small, satisfying change clears the fog!