---
title: "Incident context in Unolia"
description: "Unolia records every outage and failed deployment as an incident, then correlates it with the deploy that caused it, the deploy that fixed it, and the commits in between."
url: "https://unolia.com/blog/incident-context"
locale: "en"
---

# Every outage says what broke it

When a client site goes down, Unolia now names the deploy that likely broke it and the one that brought it back.

An alert tells you a site is down. It does not tell you why, and the ten minutes you spend answering that yourself are the ten minutes the client is watching.

Unolia now keeps incidents.

When a monitored check goes red or a deployment ends badly, an incident opens and stays open until things recover. It carries a severity that reflects what actually happened, so an uptime failure and a quietly failed zero-downtime deploy do not arrive shouting the same thing. A site that flaps in and out over a few minutes stays one incident rather than twenty.

Then Unolia goes looking for the cause. It reads back through your deployments for the one that lands closest before things broke, and forward for the one that coincides with the recovery. Between those two it walks the commit ancestry and shows you what shipped, with the person who merged each pull request, read from GitHub and GitLab alike. When an outage arrives minutes after a failed deploy, the two are linked and the incident is graded by the worse of them.

None of it is stated more confidently than it deserves. When the exact moment a check broke cannot be known, Unolia says the start is approximate and lowers its confidence in the cause accordingly. And because every pass recomputes from scratch, a guess made during the outage corrects itself once the outage ends.

What you get is the paragraph you were going to write by hand: it broke here, this is what shipped just before, this brought it back.

[whatsdiff.app](https://whatsdiff.app) is one of my own sites. When it went down, Unolia dated the outage to whenever it had last happened to poll rather than to when the site actually broke. The monitoring sync runs hourly now, and an incident says out loud when its start is a guess.

The outage on loopline.app, with the deploy that broke it and the deploy it recovered on. Demo workspace · Sample data