When the site goes down, the outage is already on the timeline.
Uptime checks your key pages every 15 minutes and logs when one goes down and when it recovers, with how long it was out. It’s not a replacement for your monitoring stack: it’s a record of outages, sitting right next to the deploy that probably caused them.
Checkout down — HTTP 503
Uptime· 14:32
Deployed storefront v2.4.0 (main → 3a7f2c1)
GitHub· 14:17
What it watches
What Uptime records.
Only the moments that matter — the transitions — so the timeline stays a record, not a heartbeat.
- Down and recovery events for up to 10 URLs, checked every 15 minutes
- A down event carries the HTTP status; the recovery event carries the outage duration
- One retry before a down event is logged, so a single blip is ignored
- Each outage sits next to that window’s deploys and config changes — the cause is usually right above it
On the timeline
What lands on your timeline.
The outage, the recovery, and — one line up — the deploy that explains it.
Tuesday, June 9
Deployed storefront v2.4.0 (main → 3a7f2c1)
14:17 · GitHub
Checkout down — HTTP 503
14:32 · Uptime
Checkout recovered — 14 min outage
14:46 · Uptime
Sound familiar?
The day you’ll wish it was written down.
Sven16:20
Tom16:24
Sven16:27
The outage left no trace.
With Uptime, the outage is already on the timeline — “Checkout down, HTTP 503” at 14:32 — one line below the 14:17 deploy that caused it.
Setup
On in two minutes.
- 01
Add your key URLs
Up to ten — your homepage, checkout, login, the pages that can’t go dark.
- 02
CoNote checks every 15 minutes
From the outside, with one retry before anything is logged.
- 03
Outages land themselves
Down and recovery events appear on your timeline, beside the changes around them.
Questions
Downtime tracking, answered.
No, and it doesn’t try to be. Uptime is a lightweight record of when your pages went down and came back, kept on the same timeline as your deploys and changes — so you can explain an outage, not get paged about one.
Every 15 minutes. Only state changes land on the timeline: a down event with the HTTP status, then a recovery event with how long the outage lasted. A single failed check is retried first, so one blip won’t log a false outage.
Up to ten. Point it at the pages where downtime actually costs you — checkout, login, the homepage.
Uptime writes outages to your timeline rather than paging you. It’s built for the after-the-fact question — “what was down, when, and what shipped right before?” — not for on-call alerting.
Keep digging
Track the rest of your stack.
- Sentry
- PagerDuty
- Datadog
- Better Stack
- Pingdom
- UptimeRobot
- Google Tag Manager
- GitHub
- Google Ads
- Google Search Console
- Shopify
- Stripe
- Meta Ads
- LinkedIn Ads
- TikTok Ads
- Vercel
- Netlify
- GitLab
- Bitbucket
- Jira
- LaunchDarkly
- WordPress
- Contentful
- Webflow
- WooCommerce
- Mailchimp
- HubSpot
- X Ads
- Buffer
- Zapier
- Site Watch
- Weather
- Webhook
- Google Algorithm Updates
- Google Analytics
Open the logbook.
Free plan, no card. Connect your first source and the timeline fills itself.
Start your logbook