Pingdom uptime history, next to the change that caused the outage.
Pingdom records every outage — down, recovered, and how long — but in its own reports, away from the deploy or config change behind it. CoNote will put each outage on one shared timeline, beside the change from the same minute.
Outage: checkout page returned HTTP 503 — 6 min
Pingdom· 14:06
Deployed checkout service v3.1.0 (main → 7b2e9a1)
GitHub· 14:02
Finding your history
Your Pingdom uptime history: today, and once CoNote is live
The manual way · inside Pingdom
Where to find it today
It’s all there — in the reports:
- 1
Open Pingdom
Sign in and open the check whose history you need — uptime is tracked per check.
- 2
Open the uptime report
Each check has an uptime report with its outages listed — start time, duration, and the error that triggered it.
- 3
Read the root cause analysis
Pingdom’s root cause analysis shows the response it got during the outage — useful, but about the symptom, not your deploy.
- 4
Compare against your other checks
Multiple checks mean multiple reports, each with its own outage list to scan.
- 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 Pingdom once. After that it’ll be seconds:
- 1
Open your CoNote timeline
Every outage will be waiting — no Pingdom access, readable by anyone.
- 2
Jump to the minute it went down
Scan the moment the outage began; it’ll be stamped right there.
- 3
See the cause beside it
The outage will sit next to that day’s deploy or config change — the trigger is one line away.
Sound familiar?
Pingdom tells you it went down — not why.
Nadja14:10
Tom14:13
Nadja14:16
Tom14:20
The outage is in one tool, the cause in another.
It answers “was the site up, and how long was the outage?” — never the question you actually have: “what did we change right before it went down?”
- Outages live in Pingdom, deploys and config live elsewhere
- Root cause analysis explains the symptom, not your change
- Per check — multiple checks mean multiple reports
- Tying an outage to a change is manual, every time
Once Pingdom is connected, the outage will already be on the timeline — “Outage: checkout page returned 503 — 6 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 Pingdom webhook
Point a Pingdom alert webhook at CoNote — no agent, no code, no engineering sprint.
- 02
Every outage logs itself
From then on, each outage and recovery lands on the timeline with a readable title — “Outage: checkout page returned 503 — 6 min” — as it happens.
- 03
Read it in context
The outage sits beside that day’s deploys and config changes — so the trigger is one line away, not one report away.
What lands on your timeline
- Outages — the check, the error, and the duration
- Recoveries, when the check comes back up
- 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 checkout page 503s. The deploy at 14:02 sits one line above the outage — so the cause is on the same page, not in a second tool.
One downtime report, causes included
Leadership wants last month’s downtime and what drove it. The outages and the deploys behind them are already on one timeline.
Spot the recurring trigger
Three 503 outages line up next to the same kind of deploy — a pattern you can finally see on one timeline.
One feed across every check
Every monitored page or endpoint’s outages land on one timeline, in order.
Side by side
Native reports vs. your logbook.
See outages and durations
Pingdom reports
CoNote
The deploy or change that caused it, beside it
Pingdom reports
CoNote
One view across every check
Pingdom reports
CoNote
Readable by the whole company
Pingdom reports
CoNote
Outages and changes on one timeline
Pingdom reports
CoNote
Setup
Pingdom reports
CoNote
On the timeline
The outage in context.
A 503 on its own is a red bar in a report. One line under the deploy from four minutes earlier, it’s a diagnosis.
Tuesday, June 9
Deployed checkout service v3.1.0 (main → 7b2e9a1)
GitHub· 14:02
Outage: checkout page returned HTTP 503
Pingdom· 14:06
Flag “new-checkout” turned on for 100% of users
LaunchDarkly· 11:20
Questions
Pingdom uptime tracking, answered.
Open a check and view its uptime report — outages are listed with their start time, duration, and the error that triggered them, and Pingdom’s root cause analysis shows the response it got. Uptime is tracked per check.
Not yet — it’s coming soon. You can start your CoNote logbook now and connect the tools that are already live; we’ll switch Pingdom on automatically the day it ships.
Only once, briefly. Connecting Pingdom will be pointing an alert webhook at CoNote — no agent and no code.
CoNote’s Uptime monitors a URL you give it. This integration brings in the outages from your existing Pingdom checks instead — so if you already run Pingdom, your downtime lands on the same timeline as everything else.
Outages and recoveries as plain-language entries — for example “Outage: checkout page returned 503 — 6 min” — with the minute they happened.
Pingdom’s reports live in its dashboard, per check, away from the deploys and config changes that cause outages. CoNote will put outages on a shared timeline right beside that day’s changes.
Only your team. Every entry is scoped to your team, and connecting Pingdom 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