Issues, alerts and incidents
Three different facts, easy to conflate, that upzero keeps as three different things.
Issues, alerts and incidents
All three of these are "something is wrong." All three have a status. That's exactly why upzero keeps them as three separate objects instead of one: each answers a different question, and forcing two of them into one table breaks the other's lifecycle.
| Answers | Created by | Closes when | |
|---|---|---|---|
| Issue | "This error keeps happening" | A recurring error class crossing a threshold | A person resolves it. If it comes back, reopening counts as a regression |
| Alert | "This condition is true right now" | A rule you configured, evaluated against your signals | The condition stops matching. A person can silence a firing alert but not close it |
| Incident | "We are responding to this" | A person, by hand or from a firing alert | A person closes it, after a timeline of updates |
Who each one is for
An issue is purely internal: an exception class with every occurrence attached, read by the people who operate the system, never shown to your customers. An incident is about user-facing impact, and carries a decision an issue never has: is it private, or is it published to your status page? That call belongs to a person on your team, not to a machine.
So the line between an issue and an incident isn't severity, and it isn't lifecycle. It's audience: an issue has one, an incident can have two, and a person decides when the second one is admitted.
How they connect
One alert can open one incident. One incident can reference several issues. An issue can sit open for months with no alert and no incident at all; nothing requires the three to appear together.
For where an issue itself comes from, see your first issue. For declaring the rule behind an alert, see resources and Kinds and Issues and alerting.