How Statsy Monitors Uptime and Notifies Users About Incidents

Statsy watches your service endpoints on a schedule, flips the matching component on your public status page when something breaks, and emails the subscribers who opted in. The whole loop — check, detect, update, notify, recover — runs without you touching the page. This applies to any team that wants a public health page without building one: you add endpoints, Statsy polls them, and visitors can subscribe for email alerts with one click.

The monitoring loop, step by step

1. You register endpoints. In the example on the site, these are URLs like https://api.yourapp.com/health, https://yourapp.com, and https://dashboard.yourapp.com. Each one maps to a component on your page (Website, API, Auth, Database, Email Delivery, Dashboard).
2. Statsy polls them. The page states a 1-minute monitoring check interval on Pro. Each check records a response, and the site's demo shows latency alongside status — 142ms Operational, 2.4s Degraded, timeout Outage.
3. A failed or slow check changes the component's state. Components show one of three values: Operational, Degraded, or Outage. Degraded and Outage are what your users see instead of a green dot.
4. The status page updates automatically. The demo notification reads: "Statsy detected that dashboard is down. Your status page has been updated automatically." You don't post the incident manually for monitored components.
5. Subscribers get email. The same notification goes to people who subscribed on your page. A follow-up arrives on recovery: "✓ Recovered: dashboard is back up."
6. Uptime history accumulates. Statsy tracks a 90-day uptime history automatically — the demo shows 99.4% and a "13 days without incident" counter.

The expected result after setup is a page at your own domain showing live per-service health, a rolling uptime figure, and a subscriber list that receives both outage and recovery emails.

What triggers a notification

The demo shows the recovery email landing 4 minutes later, which reflects the check interval rather than a fixed delay — a shorter interval means faster detection and faster recovery notices.

Scheduled maintenance

Maintenance is a separate, manual entry rather than something monitoring infers. In the example, a "Migration + Infrastructure Upgrade" is posted with a date and window (May 30, 2026 · 1:00 AM – 2:00 AM), a description, and an explicit Affected list (Website, API). It carries a Completed state once the window passes, and past incidents are listed separately as Resolved with a short cause note — for instance "Elevated response times on /v1 endpoints. Resolved after scaling connection limits."

So the page distinguishes three kinds of history: automatic uptime data, incidents Statsy detected, and maintenance you scheduled in advance.

What subscribers actually do

Visitors don't need an account. The page offers a one-click Subscribe for email alerts, and the site describes it as "no account needed for visitors." That matters for adoption: your users can opt in from the page itself during an incident, which is exactly when they're most motivated to.

Setup and plan conditions

• Setup time: the site claims under 5 minutes from signup to a live page, with a 5-minute average.
• Cost to start: $0 on the free plan, forever, and signup requires no credit card.
• Custom domain: status.yoursite.com is listed as a paid-plan feature, so on the free plan expect the hosted Statsy URL rather than your own subdomain.
• Check interval: the 1-minute interval is a Pro feature; the free plan's interval isn't stated on the page, so treat faster detection as a paid upgrade rather than a default.
• No onboarding calls: the site explicitly positions this as self-serve — "no onboarding calls, no complexity."

If your priority is a public page your users can check and subscribe to within an afternoon, the free plan covers the core loop. If you need your own domain on the page or minute-level detection, budget for a paid tier — the page doesn't publish prices, so check the pricing page before committing.

Where this breaks down in practice

• Health endpoints that lie. If /health returns 200 while your database is unreachable, Statsy reports Operational. Monitor the dependency directly (the demo tracks Database as its own component) rather than trusting one aggregate endpoint.
• Slow ≠ down. A 2.4s response shows as Degraded, not Outage. Decide with your team whether Degraded should page anyone, since it will email subscribers.
• Recovery lag. With a 1-minute interval, a brief blip can produce an outage email followed by a recovery email minutes later. Subscribers see both; consider whether that noise is acceptable before promoting the subscribe link widely.