Something went wrong on your client's site last night. Uptime came back after 12 minutes, PageSpeed dropped by 37 points, and you have a client call in an hour. You open Slack, dig through deploy logs, check your uptime tool, and try to piece together a timeline by hand.
This is the post-incident experience for most agencies — and it's genuinely terrible. Not because the data doesn't exist, but because it's scattered across four different tools and three different tabs. Today, we're shipping AI Incident Timeline: a single chronological view of every deploy, downtime event, alert, and recovery across your site — with an AI-generated summary at the top that tells you what happened in one sentence.
The problem with post-incident analysis today
When something breaks in production, you need to answer three questions fast: what changed, when did it break, and what fixed it? The answers exist in your monitoring data — but they're distributed. Your uptime tool recorded the downtime window. Your deploy log shows when you pushed. Your PageSpeed history shows the score drop. Your alert log shows who got notified.
Nobody correlates these automatically. So you do it by hand, under pressure, while the client is waiting. AI Incident Timeline does the correlation for you.
What the timeline shows
Every event that SiteBrief captures for a site is now surfaced in a single chronological feed. The timeline includes five event types:
The AI summary at the top
Above the timeline, SiteBrief generates a single-sentence root cause summary using Claude AI. It reads all the signals — deploy timing, downtime window, PageSpeed change, alert data — and produces something like:
"Deploy at 14:02 caused 12-minute downtime — PageSpeed dropped from 78 to 41 and the site returned 503 errors until a hotfix was pushed at 14:14."
This summary is exactly what you paste into the client Slack message or the post-mortem report. No editing required. It's generated fresh each time you open the timeline, so it always reflects the most recent data.
Filters: find what matters
For sites with frequent deploys, the raw timeline can get long. The filter bar at the top lets you narrow to exactly what you need:
Filter to Downtime only and you see every outage window with duration and resolution status. Filter to Deploy and you see every push with the associated commit SHA, branch, and author — making it easy to identify which deploy triggered a regression.
Automatic deploy-to-downtime correlation
The most useful thing the timeline does is connect deploys to downtime automatically. When SiteBrief detects an outage, it looks back at the previous 30 minutes of deploy events and draws a link if there's a plausible causal relationship. The deploy event in the timeline gets a "Likely cause" badge, and the downtime event shows the connected deploy commit.
This isn't just helpful for the post-mortem — it also feeds the AI Incident Summary at the top. When the correlation is high-confidence, the summary explicitly names the deploy as the cause rather than hedging.
What counts as a "plausible" link?
SiteBrief considers a deploy a likely cause of downtime if: the downtime started within 10 minutes of the deploy completing, the pre-deploy uptime was stable for at least 30 minutes, and the post-deploy scan shows at least one new critical issue not present in the previous scan.
How far back does the timeline go?
The default view shows the last 30 days of events. You can extend it to 90 days using the date picker in the top-right corner. All events are stored for the lifetime of your account — you can always go back and reconstruct what happened on any specific date.
- Deploy events are captured via GitHub/GitLab webhook — no extra configuration needed if you've already connected your repo
- Downtime events come from SiteBrief's uptime monitoring (checked from 3 global locations every 60 seconds)
- PageSpeed events are recorded on every deploy scan and every 24-hour scheduled scan
- Alert events show who was notified and via which channel (Slack, email, PagerDuty)
Using the timeline in client reports
The timeline has a Share button that generates a read-only link. You can send this directly to a client so they can see the exact sequence of events — deploys, downtime, recovery — without giving them access to the full dashboard. It's the fastest way to answer "so what actually happened?" in a professional way.
The AI summary also appears in the monthly PDF report if you have white-label reporting enabled, in the "Incident History" section alongside MTTR statistics.