For the complete documentation index, see llms.txt. This page is also available as Markdown.

Getting started

Coordinate your response to an incident, and communicate it to the people who depend on you — while keeping the two apart.

Two jobs run at once during an outage. Coordinating the response is internal, fast and messy. Communicating it is external, deliberate and slow. ilert keeps them separate on purpose, so nothing reaches your customers until you decide it should.

Why it matters

  • Your responders work in one place instead of across a dozen noisy alerts.

  • Your customers hear something, which is what stops them opening tickets.

  • Nothing internal leaks by accident, because publishing is always a separate act.

The building blocks

  • Services model the capabilities your users care about — Checkout, Search, Login. Everything else references them: alerts attach to them, incidents name them, status pages display them, and people subscribe to them.

  • Incidents are the coordination record for a significant event. Declaring one links the alerts, pages the responders, keeps the timeline, and runs the response to resolution.

  • Postmortems are the write-up once the impact has ended: why the incident happened, and what stops it happening again. ilert AI can draft one from the incident for you to finish.

  • Status updates are the public half. They appear on your status pages and reach subscribers. Until you post one, the incident appears on none of your status pages.

  • Status pages are the public or private pages that show current service status and the history of what you have published.

  • Metrics put numbers next to those statuses, either posted by you or imported from Datadog or Prometheus.

  • Service topology reconstructs how your services depend on one another from OpenTelemetry traces, so you can see the blast radius of a failure rather than guess it.

How it fits together

An alert pages whoever is on call. If it turns into something that needs more than one person, you declare an incident — the internal hub where the team works the problem. Responders, the timeline and the chat channel all hang off the incident, not off the alert.

If customers are affected, you post a status update from that incident. Only then does the incident show on a status page, and only then are subscribers told. Internal detail stays internal; the public message is written on purpose.

When the impact has ended, you write the postmortem for that same incident. It stays internal unless you choose to show it on your status pages, and then only on the pages the incident already appeared on.

Last updated

Was this helpful?