Skip to content

Incidents

Confirm incidents before they distract the whole team.

Not every failed check deserves a company-wide alarm. Latensy helps teams distinguish suspicious signals from confirmed incidents, so attention goes where it is actually needed.

From suspicious blip to confirmed incident

Each service has its own rule for how many consecutive failed checks it takes to open an incident, and how many consecutive successes it takes to recover. A single timeout is a signal to watch, not a reason to page everyone.

  • Consecutive-failure threshold per service, configured when you add it
  • Failing checks below the threshold show as degraded, not down: visible without paging anyone
  • Confidence levels: suspected, likely, confirmed
  • Severity: critical, high, medium, low, influenced by service criticality
  • Cause, duration, and degraded duration recorded on every incident
  • Recovery tracked separately, so flapping services do not spam alerts

In the product

Every incident with its confidence, cause, and who was told.

Maintenance windows

Declare planned work for all services or specific ones. Checks inside the window are skipped for incident detection, so a deploy never becomes a false incident or a wasted alert.

Alerts that mean something

Alerts go to email, Slack, or webhooks only when an incident is confirmed, and again when it recovers. Test any channel before you rely on it.

Resolve from Mission Control

Active incidents sit at the top of Mission Control with their service, criticality, and timing. Resolve one or all with a click once the team has handled it, and the record stays in the incident history.

Fewer false alarms. Faster certainty.

Add your five most critical services, set their confirmation rules, and connect one alert channel. The Free plan is enough to see the difference.

Start monitoring Book a demo