Monitoring · Available on All tiers

Monitor the endpoint that actually matters, not just the homepage.

GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS — with custom headers, a request body, and assertions on the response — so your checkout webhook gets the same attention as your landing page.

Start Free → See pricing

Free forever plan, no card required.

Why it matters

Real API monitoring

Most uptime tools ping a homepage and call it monitoring. Your homepage can return a 200 while your payment webhook, your auth endpoint, or your internal API is silently broken. If the thing your business depends on isn't a GET request to "/", a homepage ping tells you nothing useful. Imagine your checkout webhook silently starts 500ing overnight — the storefront still loads fine, the marketing pages are all green, and the first sign anything's wrong is a finance team asking why yesterday's orders never got fulfilled. A tool built around a single GET request to your homepage would never have caught it, because it was never watching the endpoint that actually mattered. Monitoring the real request — the right method, the right headers, the right body — is the difference between knowing about a broken integration in minutes and finding out from an angry customer days later. It's the same reason a smoke detector in the kitchen doesn't help if the fire starts in the garage — you have to watch the part of the house that's actually at risk. That kind of gap is exactly how a team ends up looking blindsided by a problem their own monitoring tool should have caught weeks earlier.

Any HTTP method

Test the exact request your app makes — GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS — not an approximation of it. If your integration only ever calls your API with a POST and a specific content type, that's what gets checked, not a generic GET that happens to hit the same URL and tells you nothing about whether the real request path actually works. That precision is what separates monitoring that reflects reality from monitoring that just gives you a comforting green checkmark. There's no need to settle for testing a nearby GET endpoint as a stand-in for the request that actually matters.

Real assertions

Check status code and keyword/body-match together, so a 200 with the wrong payload still counts as down. A broken deploy that returns a 200 with an empty JSON body, a stale cache, or an error message wrapped in a success response would sail past a status-code-only check — this catches it because the response body has to actually look right, not just arrive with the right number attached. It's a small addition to set up and a large one to actually catch. It's the sort of failure mode that a status-code-only tool is structurally incapable of ever catching.

Custom headers & body

Send auth tokens, content-type, and a JSON payload — whatever the endpoint actually expects to receive. That means monitoring an authenticated internal API the same way your own services call it, instead of only being able to watch the handful of public, unauthenticated endpoints a simpler tool is limited to. That flexibility is what makes it useful for more than a handful of simple public-facing checks. Nothing about the request has to be simplified or approximated just to fit what the monitor supports.

FAQ

Real API monitoring, answered.

Does this work for authenticated endpoints?

Yes — send custom headers, like an auth token, and a JSON request body with any check, so the request UptimeLuna sends matches what your app actually expects to receive. That includes bearer tokens, API keys in a header, or whatever authentication scheme your endpoint already uses, so you're not limited to monitoring only the public, unauthenticated parts of your API. The same goes for OAuth tokens, session cookies, or any custom scheme your API already relies on. It's the same authentication your app already uses in production, replicated exactly for the check.

What counts as a failed check?

You set the rule: a specific status code, a keyword/body match, or both together — so a 200 response with the wrong payload still counts as down, not just a non-2xx status. That matters most for endpoints that fail gracefully, returning a technically successful response that's actually empty, stale, or wrapping an error message nobody would notice without checking the body. Combine both conditions on the same check for the strictest possible definition of "working." Either rule alone catches a lot; both together catch nearly everything worth catching.

Can I monitor an internal API that isn't public?

Yes, as long as UptimeLuna's runners can reach it over the internet — most internal APIs sit behind auth rather than a network firewall, which is exactly what custom headers and a request body are for. If the endpoint is fully walled off on a private network with no public route at all, it isn't reachable from outside, the same limitation any external monitoring tool would run into. The same principle applies to anything sitting behind a VPN or a private subnet with no public entry point. Reachability, not visibility, is the only real requirement here.

Get Started

Real API monitoring. Free, starting now.

Start Free →