If your API answers on QUERY, you can now point a monitor straight at it.
QUERY joins HEAD, GET, POST, PUT, PATCH, DELETE, and OPTIONS in the HTTP method list for HTTP, keyword, and API monitors. You can find it under the “Advanced settings” when editing or adding your monitor.
QUERY became a standard in June 2026 as RFC 10008. It’s safe, idempotent, and it carries a request body. That combination did not exist in HTTP before, and search endpoints have been paying for the gap for twenty years.
The gap QUERY fills
A search endpoint reads. It changes nothing on the server, so repeating it is harmless. It also needs to accept a structured payload, sometimes a big one. Until now you had to give up one of those two things.
GET is safe and idempotent, but it has no defined body semantics, so the query goes in the URL. RFC 9110 recommends handling at least 8000 octets of request line, and intermediaries disagree about anything past that. Long filters get truncated somewhere between your client and your server. Sensitive ones land in access logs and browser history.
POST takes a body of any size and puts none of that at risk. What it gives up is meaning. POST is not safe and not idempotent, so a proxy will not retry it and a cache will not store the response. Nothing in the protocol tells an intermediary that a POST to /search is harmless to repeat, no matter what your API docs say.
QUERY declares both properties and expects a body. The declaration lives in the IANA method registry, not in your documentation, so caches and proxies can act on it without knowing anything about your API.
How the three methods compare
| Property | GET | QUERY | POST |
|---|---|---|---|
| Safe | Yes | Yes | Not necessarily |
| Idempotent | Yes | Yes | Not necessarily |
| Request body | No defined semantics | Expected | Expected |
| URI identifies the query | Yes, by definition | Optional | No |
| Response cacheable | Yes | Yes | Only for a later GET or HEAD |
The row that matters for monitoring is the last one. A cached QUERY response is keyed on the request body, not the URL, which means two monitors hitting the same endpoint with different payloads are two different checks as far as every cache in the path is concerned.
Turn it on for a monitor
Click on the the monitor under the “Monitoring” tab, expand “Advanced Settings” below, and pick QUERY under HTTP Method.
Add the request body the endpoint expects, either as raw JSON or as key-value pairs, plus any custom headers. Then set which response codes count as up.
Everything else behaves the way it always has.
Check intervals, regions, alert contacts, response time tracking, and keyword checks against the response body all work the same on a QUERY monitor as on a GET one. You can also set the method through the v3 API if you manage monitors as code.
What to watch for while adoption catches up
The RFC is two months old. Most servers that speak QUERY today kept their POST endpoint running alongside it, and that is the sensible way to ship it.
Two things tend to bite. Browsers do not treat QUERY as a safelisted method, so cross-origin calls trigger a CORS preflight and pay the extra round trip. And any hop that has not been updated, a framework router, a reverse proxy, a WAF rule written against a method allowlist, answers QUERY with 405 Method Not Allowed while POST sails through.
That second one is worth a monitor of its own. If you run QUERY and POST side by side, a check on the QUERY path tells you the moment something in the chain starts rejecting the method, and running it from the regions you pick tells you whether the rejection is global or sitting in one edge location.
-
A method for requests that read data and need a request body to describe what to read. It was defined in RFC 10008, published by the IETF in June 2026 as a Proposed Standard. Think of it as GET with a body, or POST that a cache and a proxy can trust.
-
Run both for now. QUERY is the correct method for a read with a payload, but client and infrastructure support is young. Add QUERY next to your existing POST route, monitor both, and retire the POST route when your traffic says you can.
-
HTTP, keyword, and API monitors. It appears in the same HTTP Method setting as the other methods, and it accepts the same request body, authentication, and custom header options.
-
Yes. A keyword monitor set to QUERY sends your body, reads the response, and alerts on a keyword being present or missing, exactly as it does on GET or POST.
