Uptime & Incident Comms
A failed probe becomes a status-page update and a customer notice before support gets flooded with tickets.
What it watches
Uptime probes on your key endpoints
What it does
Updates your status page and notifies affected customers automatically when a probe fails repeatedly
When it asks a human first
Severity 2 or above pages your on-call channel immediately — the agent handles comms, never the actual fix to the underlying outage. A service that flaps — recovering and failing repeatedly within a short window — escalates as a single ongoing incident rather than paging fresh on every bounce, so on-call is not drowned in duplicate alerts for the same underlying problem.
How it works
- 1Probes your endpoints
Runs continuous health checks against the URLs and services you specify. Checks run from multiple geographic regions by default, so a routing problem local to one network is never mistaken for your service actually being down everywhere.
- 2Confirms before alerting
Waits for N consecutive failures (your threshold) before treating a blip as an incident — no alert fatigue from a single dropped check. The threshold is configurable per endpoint, not fixed globally, so a payment API you would flag on the second failure can sit next to a marketing page you are happy to give five.
- 3Updates the status page
Posts an incident entry to your public status page automatically, so customers see it before they need to ask. The entry names only the affected component — checkout, API, dashboard — never a blanket "systems down" that overstates a partial outage into a full one.
- 4Notifies affected customers
Sends a notice to accounts using the affected service, not a blast to your entire customer base. It cross-checks which accounts actually touched the affected component in the recent window, so a customer who never uses that feature does not get an alarming notice about downtime irrelevant to them.
- 5Closes the loop
When the probe recovers, it posts a resolution update and a downtime summary — the fix itself is still on you. A recovery has to hold for a few consecutive clean checks before it posts the all-clear, so a service that flaps back up for thirty seconds and drops again is not falsely marked resolved.
What triggers it
- · A probe on a monitored endpoint fails once
- · A probe fails N consecutive times past your threshold
- · A failed endpoint recovers
- · An incident crosses your defined severity level
What you get
- · A status-page update posted automatically at incident start and resolution
- · A customer notice sent to affected accounts
- · An internal alert to your on-call channel (Slack/Telegram)
- · A post-incident summary with downtime duration
Not the right fit if
Not for static marketing sites with no uptime-sensitive service behind them — there is nothing here worth a status page. It’s also not the right layer if you’re already running a dedicated incident-management stack (PagerDuty, Statuspage, an SRE on-call rotation) — this agent is built to be the whole lightweight loop for a team that doesn’t have one yet, not a bolt-on next to an escalation system that already exists.
The math
At ~4 incidents/mo × 20 min, that is roughly 1.3 h/mo — an estimate, not a guarantee.
Frequently asked
No — it handles detection and communication. Someone on your team still fixes the actual problem.
As many as you list at setup — pricing scales with the number of monitored endpoints and check frequency.
Yes — internal alerts and customer comms can go to different channels simultaneously.
You define the thresholds at setup — typically a core service down vs. a degraded but functional one.
Yes — a response-time threshold runs alongside the pass/fail check, so a page that loads but takes ten seconds instead of one still triggers a degraded-performance incident, not just a hard outage.
Ready to put uptime & incident comms to work?
Tell us about your setup and we'll confirm it fits within 48 hours.