Better Stack incident history, next to the change that caused it.
Better Stack catches every outage — started, acknowledged, resolved — but in its own dashboard, away from the deploy or config change behind it. CoNote will put each incident on one shared timeline, beside the change from the same minute.
Incident resolved: storefront down — 8 min
Better Stack· 14:06
Deployed storefront v3.1.0 (main → 7b2e9a1)
GitHub· 14:02
Finding your history
Your Better Stack incident history: today, and once CoNote is live
The manual way · inside Better Stack
Where to find it today
It’s all there — in the dashboard:
- 1
Open Better Stack
Go to the Incidents view for the monitor you’re investigating — incidents are grouped per monitor.
- 2
Find the incident
Each incident shows when it started, who acknowledged it, and when it resolved, with the downtime duration.
- 3
Open its detail
The incident detail includes the screenshot or response that triggered it, and the timeline of acknowledgements.
- 4
Check the status page
If you publish a status page, past incidents live there too — but written for customers, not lined up against your changes.
- 5
Cross-reference the deploy by hand
To tie an outage to a deploy or config change, you switch tools and line the timestamps up yourself.
The CoNote way · coming soon
Where you’ll find it once it’s live
Connect Better Stack once. After that it’ll be seconds:
- 1
Open your CoNote timeline
Every incident will be waiting — no dashboard access, readable by anyone.
- 2
Jump to the minute it started
Scan the moment the outage began; it’ll be stamped right there.
- 3
See the cause beside it
The incident will sit next to that day’s deploy or config change — the trigger is one line away.
Sound familiar?
Better Stack tells you it’s down — not why.
Nadja14:10
Tom14:13
Nadja14:16
Tom14:20
The outage is in one tool, the cause in another.
It answers “is the site up, and how long was the outage?” — never the question you actually have: “what did we change right before it went down?”
- Incidents live in Better Stack, deploys and config live elsewhere
- Status pages tell customers the window, never the cause
- Per monitor — no single view across everything that moved
- Tying an outage to a change is manual, every time
Once Better Stack is connected, the incident will already be on the timeline — “Incident resolved: storefront down — 8 min” at 14:06 — right under the 14:02 deploy, so the cause is one line away.
How it works
Connect once. Then it’ll log itself.
- 01
Add a Better Stack webhook
Point a Better Stack webhook at CoNote — no agent, no code, no engineering sprint.
- 02
Every incident logs itself
From then on, each incident started, acknowledged, and resolved lands on the timeline with a readable title — “Incident resolved: storefront down — 8 min” — as it happens.
- 03
Read it in context
The incident sits beside that day’s deploys and config changes — so the trigger is one line away, not one dashboard away.
What lands on your timeline
- Incidents started, acknowledged, and resolved
- How long each outage lasted
- The minute it happened, beside the change that caused it
In your week
What teams will use it for.
The outage with an obvious cause
The storefront goes down. The deploy at 14:02 sits one line above the incident — so the cause is on the same page, not in a second tool.
Answer support without engineering
When customers ask about downtime, the incident and the deploy behind it are both on one timeline, in plain language.
Spot the repeat trigger
Two outages this week line up next to the same kind of change — a pattern you can finally see on one timeline.
One feed across every monitor
Every monitored service’s incidents land on one timeline, in order, the whole team can read.
Side by side
Native incidents vs. your logbook.
See incidents and downtime
Better Stack incidents
CoNote
The deploy or change that caused it, beside it
Better Stack incidents
CoNote
One view across every monitor
Better Stack incidents
CoNote
Readable by the whole company
Better Stack incidents
CoNote
Incidents and changes on one timeline
Better Stack incidents
CoNote
Setup
Better Stack incidents
CoNote
On the timeline
The incident in context.
An outage on its own is a red bar on a status page. One line under the deploy from four minutes earlier, it’s a diagnosis.
Tuesday, June 9
Deployed storefront v3.1.0 (main → 7b2e9a1)
GitHub· 14:02
Incident started: storefront down
Better Stack· 14:06
Flag “new-checkout” turned on for 100% of users
LaunchDarkly· 11:20
Questions
Better Stack incident tracking, answered.
Open the Incidents view for a monitor — each incident shows when it started, who acknowledged it, the downtime duration, and when it resolved. Past incidents also appear on your status page if you publish one.
Not yet — it’s coming soon. You can start your CoNote logbook now and connect the tools that are already live; we’ll switch Better Stack on automatically the day it ships.
Only once, briefly. Connecting Better Stack will be pointing a webhook at CoNote — no agent and no code.
CoNote’s Uptime monitors a URL you give it. This integration brings in the incidents from your existing Better Stack monitors instead — so if you already run Better Stack, your outages land on the same timeline as everything else.
Incidents started, acknowledged, and resolved, as plain-language entries — for example “Incident resolved: storefront down — 8 min” — with the minute they happened.
Better Stack’s incidents live in its dashboard, per monitor, away from the deploys and config changes that cause them. CoNote will put incidents on a shared timeline right beside that day’s changes.
Only your team. Every entry is scoped to your team, and connecting Better Stack won’t expose your account to anyone outside it.
Keep digging
Track the rest of your stack.
Open the logbook.
Free plan, no card. The next time someone asks “what changed?”, the answer is one search away.
Start your logbook