Fewer false pages
A failed HTTP check that the second region can't reproduce is set aside before it alerts. That filters out most of the 3 a.m. pages that turn out to be a dropped packet. When Hoppla wakes you, two locations saw the failure.
Uptime Monitoring
When Hoppla pages you, two regions saw the site fail. A blip from one location is re-tested before your phone buzzes.
Hoppla watches your HTTP, TCP, and ping endpoints from probes in Germany and Finland. A failed HTTP check gets re-run from Finland before anyone gets alerted, so a real 503 wakes you and a packet that died somewhere between Falkenstein and your front door usually doesn't.
UP / SAMPLE OUTPUTIllustrative example
GET /healthz fsn:503 -> recheck hel:503 -> CONFIRMED · p95 412ms
Fictional values. Not a live measurement.
01 / What it does
An alert you can actually trust
Hoppla hits your HTTP/HTTPS endpoints, raw TCP ports, and ping targets from its German probe, as often as every 60 seconds (every 30 on Starter and Pro). When an HTTP check fails, the Finnish probe re-runs it right away. An incident opens only after both regions agree, by default on two confirmed failures in a row. A one-off hiccup Finland can't reproduce is logged and left out of your uptime figure, not sent to your phone.
What’s included
- ✓HTTP/HTTPS, raw TCP, and ping (ICMP) checks
- ✓Dual-check verification: every failed HTTP check re-tested from a second region
- ✓Probes in Germany and Finland, intervals down to 60s (Free, Hobby) or 30s (Starter, Pro)
- ✓Assertions on status code, body keyword/substring, and response headers
- ✓Expected final URL after redirects, plus a max-redirect limit
- ✓Custom method, headers, body, basic auth and query parameters per check
- ✓Response-time p95 plus connect, TLS and first-byte timing, on one shared timeline
02 / How it works
Under the hood.
01
Probe from one region
A scheduled worker hits your endpoint from one region. For HTTP it follows redirects up to your max-redirect limit and reads status, headers, and body. TCP opens the socket. Ping sends ICMP. That's the first opinion, not the verdict.
02
Run your assertions
A 200 isn't the finish line. Hoppla checks the status code you expect, matches a keyword or substring in the response body, asserts on response headers, and confirms the final URL after redirects. Miss any of those and it's a failure, not just a non-2xx.
03
Re-confirm from the second region
A failed HTTP check doesn't alert on its own. Hoppla fires the same check from the other region. If region two sees a healthy response, the blip is logged and left out of your uptime figure. If both agree, it counts as a confirmed failure. By default two in a row open the incident, and only then does anyone hear about it.
04
Record latency, then page you
Every run stores response time, split into connect, TLS, first byte and transfer, with a p95 line on the chart, so you see where the time went instead of one blended average. The confirmed incident lands on the monitor's single timeline and fires your alert channels. Worth being clear: this is monitoring, not an APM. No traces, no flame graphs. We tell you the request failed, from where, and what it returned.
03 / Why it matters012 regions 0260s 03p95
The part that actually moves the needle.
You hear it early
Checks run as often as every 60 seconds, or every 30 on Starter and Pro. The second-region re-check is queued right after a check fails, not on the next interval. By default two confirmed failures open the incident and a 60-second grace precedes the alert; both are adjustable per monitor.
Slowness has an address
Response time is tracked with a p95 line and split into connect, TLS, first byte and transfer. You can show whether the time went to the network, the handshake or your server, instead of arguing over a single blended number.
04 / For every team
Whoever you are, this lands differently.
Solo SaaS founder
You ship alone, and the phone sleeps on the pillow next to you. The thing that burns you out isn't downtime. It's the 2 a.m. page that was nothing. Hoppla's second-region recheck filters most of those out quietly. It wakes you when both regions see your app throwing 503s, so far fewer buzzes turn out to be nothing.
Small agency
You run 5 to 30 client sites and nobody's the designated "monitoring person." Each site is one monitor (uptime, status assertions, SSL) on a single timeline, so you scan one board instead of a dozen logins. When a client's checkout starts redirecting somewhere wrong, the expected-final-URL assertion flags it on the next check, often before the client calls you.
Large agency
You manage hundreds of sites, and account managers field client questions about performance. The p95 line and the connect/TLS/first-byte split drop straight into a report: network steady, time lost waiting on the server. Body and header assertions let you watch the actual app response across the whole fleet, not just whether a server answered the door.
Reseller / hosting provider
You white-label Hoppla and resell monitoring under your own brand and domain. Dual-region verification runs across your entire customer base with your name on the alerts and status pages. Body and header assertions check what each customer's site actually returns, not just whether the edge answered.
Switching tools
Coming from Uptime Robot? Bring your monitors with you.
Import your Uptime Robot monitors into Hoppla. Then run both side by side for 24 hours or 7 days before you switch.
- ✓ Guided import
- ✓ Shadow run before you switch
- ✓ Coverage varies by provider
Import from
- Oh Dear
- Uptime Robot
- Better Stack
- Pingdom
- StatusCakeBeta
- CronitorBeta
- Healthchecks.ioBeta
- Statuspage
The importer opens in your workspace once you have access.
Get early accessFOR HOSTERS & RESELLERS
See the reseller program Run dual-region availability across your entire customer base, white-labeled, alerting under your brand, billed as yours.
05 / FAQ
Straight answers.
How is this different from Uptime Robot?
Uptime Robot alerts on a single failed check from one location, which is why it pages you for transient network blips. Hoppla re-tests every failed HTTP check from the second region before alerting, and it asserts on the response body, headers, and final redirect URL, not just whether the server returned a 2xx.
Does the dual-check verification slow down my alerts?
Barely. The recheck is queued right after the first failure, not on the next interval, so it typically adds seconds. Your alert time comes from the monitor's rule: by default two confirmed failures plus a 60-second grace, both adjustable.
My site is behind a CDN — am I just monitoring the cache?
By default you monitor what visitors get, which is the CDN's answer. To watch the backend too, point a second monitor at a hostname the CDN doesn't cache, or add an application-health check that reports from inside your app, so a sick backend shows up even while the edge serves cached pages.
Can I check more than a 200 status?
Yes. Set the exact status code you expect, require a keyword or substring in the response body, assert on specific response headers, and confirm the final URL after redirects. A page that returns 200 but renders an error counts as down once one of those rules catches it.
Your next step
Fewer pages for nothing. Uptime confirmed from two regions.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.