Introduction
What statusloop is, how checks work, and where to go next.
statusloop helps small teams know when their websites, APIs, cron jobs, and servers stop working — before customers notice. You get monitors, heartbeat checks, server metrics, incidents, escalation policies, and public status pages in one workspace at app.statusloop.dev.
How a check works
1. Check runs
statusloop probes your URL, TCP port, or waits for a heartbeat ping on the schedule you set (as fast as every 10 seconds on Business).
2. Failure is confirmed
Monitors need two consecutive failed check cycles before going down — so one flaky result does not wake anyone up.
3. Incident opens and alerts go out
An incident is created with a timeline. Your escalation policy sends alerts through the channels you configured (email, Slack, Discord, and more).
4. Recovery is confirmed
After two successful cycles (and at least one minute since the incident opened), statusloop marks the incident resolved and notifies your team.
Avoiding false alerts
- Confirmation cycles — monitors and servers wait for repeated failures before alerting.
- Healthcheck grace periods — cron jobs get extra time after the expected ping before statusloop calls it down.
- Mute — pause a noisy monitor for 30 minutes, 1 hour, 24 hours, or until you unmute it.
- Slowdown while failing — after five failed cycles, check frequency drops to every 15 minutes until recovery.
Monitor types
What should you monitor?
- Marketing website — the page customers land on.
- Web app — login, dashboard, or checkout flows.
- API — a
/healthor/api/statusendpoint your app already exposes. - Cron jobs — nightly backups, report generators, queue workers (via healthcheck ping URL).
- Third-party dependencies — payment provider status page, auth provider, or any URL your product relies on.