Hoppla polls a JSON health endpoint inside your own app and reads back the things only your app can see: queue depth, disk filling up, failed jobs, a flaky third party. It speaks Oh Dear's format natively, with the same secret header and the same { finishedAt, checkResults[] } shape, so an Oh Dear health endpoint you already shipped works with zero code changes. One sub-check failed or crashed and the monitor goes down. And a stale or misconfigured endpoint? It warns you, instead of reporting a green it hasn't earned.
GET /health [oh-dear-health-check-secret] 200 · 7/8 ok · queue:failed depth=4120 -> DOWN
Fictional values. Not a live measurement.
Your app already knows things an HTTP probe never will: how deep the queue is, whether the disk is filling, if the nightly job stack is throwing. Hoppla calls a JSON endpoint you expose (/health by default), sends the oh-dear-health-check-secret header, and reads back your sub-checks. One reports failed or crashed, the monitor goes down. If the endpoint 401s, returns something that isn't JSON, or reports a finishedAt older than five minutes, you get a warning that the check itself is broken. Not a false green.
You build an endpoint (/health by default, or any path you set) that runs your internal checks and returns { finishedAt, checkResults[] }. It's the exact shape Oh Dear uses, so an existing Oh Dear health endpoint works here unchanged. Each sub-check carries a name and a status: ok, warning, failed, crashed, or skipped.
On each run Hoppla requests the endpoint with the oh-dear-health-check-secret header set to your shared secret. Your app can turn away any request that doesn't carry it. The request times out after 10 seconds by default. Path, secret, and timeout are set per monitor.
Hoppla parses up to 100 sub-checks. ok and skipped pass, warning (or a status it doesn't know) warns, and any sub-check that's failed or crashed takes the whole monitor DOWN. A 5xx, a timeout or an unreachable endpoint does the same. All of them passing? A clean OK, on one timeline beside your uptime and SSL.
A health check that can't report is its own failure mode. A 401/403/404/501, a non-JSON body, or a finishedAt older than the 5-minute stale threshold each raise a WARNING. Not a silent pass. Not a fake outage. You hear that the endpoint stopped reporting before you start trusting a stale green.
An HTTP 200 means the web server answered. It says nothing about a queue at 4,000 jobs, a disk at 98%, or a failed-job table climbing. Report up to 100 internal sub-checks, and the monitor goes down on the ones a probe outside your app can never reach.
Hoppla sends the oh-dear-health-check-secret header and expects the same { finishedAt, checkResults[] } JSON. An Oh Dear health endpoint moves over with no code change: point Hoppla at the same URL and secret, and it reads it.
A finishedAt older than the 5-minute stale threshold, or a 401/404/non-JSON response, raises a WARNING instead of a false OK. Warning sub-checks don't open an outage either: they send one warning per episode, and skipped counts as passing, so you can surface soft signals without crying wolf.
Your site is up, but the email queue stopped draining three hours ago and the welcome mails aren't going out. An uptime check would never notice, because the homepage still returns 200. Add a queue-depth and failed-jobs sub-check to your /health, and Hoppla takes the monitor down on the next poll after the backlog crosses your line (every 5 minutes by default). You find out from the alert on your nightstand, not from a customer asking where their confirmation email went.
Every client app is wired differently, so 'is it healthy?' means something different on each one. Standardize it. Ship the same /health endpoint into every project, each one exposing that app's own checks: disk on one, a payment webhook on another, Redis on a third. Hoppla polls them all with per-monitor secrets, and one failed sub-check anywhere lights up the same board you already scan for uptime and SSL. No client-specific runbook to keep in your head.
You run hundreds of services. 'The site is up' is a question account managers can answer themselves; 'is the app actually well?' is the one that needs the truth. Each service's endpoint reports up to 100 internal sub-checks, and Hoppla rolls every one onto a single timeline per monitor. A failed background-worker sub-check on one client's app surfaces right next to its uptime and certs, so the at-risk service shows up in the fleet view instead of hiding behind a healthy front page.
Anyone can resell 'is it up.' Deep app-health monitoring is the tier customers pay more for. Hand a customer your /health spec, or point Hoppla at the Oh Dear endpoint they already built, and sell monitoring of their queues, disk, and jobs under your own brand and domain. Because it reads the Oh Dear format, moving a customer off Oh Dear onto your product is a config change, not an integration project, and the alerts arrive wearing your name.
Import your Oh Dear monitors into Hoppla. Then run both side by side for 24 hours or 7 days before you switch.
The importer opens in your workspace once you have access.
Get early accessYes. Hoppla sends the same oh-dear-health-check-secret header and reads the same { finishedAt, checkResults[] } JSON shape Oh Dear defined. Point Hoppla at the existing URL, set the same secret, and it parses your sub-checks as-is. One gap: the stale-result warning reads finishedAt only as a date string, not as the Unix timestamp Oh Dear uses, so staleness isn't flagged on those endpoints yet.
An uptime check confirms your server answered HTTP. This one asks your app whether it's healthy inside. You decide what that means (queue depth, disk space, failed jobs, a third-party dependency) and report each as a sub-check. The monitor goes down when one of those fails, even while the homepage is still returning a clean 200.
You get a warning, not a false green and not a fake outage. A 401/403/404/501, a non-JSON body, or a finishedAt older than the 5-minute stale threshold each raise a WARNING that the check is misconfigured or stale. A health check you can't trust is its own problem, and Hoppla flags it as one.
Up to 100 sub-checks per endpoint. Hoppla normalizes each to ok, warning, failed, crashed, or skipped. Any sub-check that comes back failed or crashed takes the whole monitor down. Warning doesn't open an outage on its own (it sends one warning per episode) and skipped counts as passing, so you can report advisory signals without raising an incident over them. One caveat worth saying out loud: this reads the health snapshot your app hands back. It's monitoring, not an APM. No traces, no flame graphs, so the why behind a failing sub-check still lives in your own logs.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.