The finding is that only one company does it
Nine companies that sell uptime monitoring were checked for whether they publish their own incident history in a form something other than eyes can read. That write-up is separate.
One of them did. Better Stack.
Every one of them has a status page a person can read. Nobody is hiding. What is missing everywhere else is a form you can line up against another company.
This cat saves that feed daily. Three and a half years of it have accumulated, so here is what it establishes and what it does not.
45 entries, back to February 2023
status.betterstack.com/feed.rss returned 45 entries, the oldest dated 7 February 2023 and the newest 20 August 2026.
By year:
| Year | Entries |
|---|---|
| 2023 (from February) | 2 |
| 2024 | 13 |
| 2025 | 21 |
| 2026 (to August) | 9 |
No count limit is declared. For comparison, among the other companies tracked here, Linear and Notion both stop at exactly 25 — sitting on a cap. Better Stack's 45 is not a cap; it is how many there are.
Do not read that table as decline
Two in 2023 against twenty-one in 2025 looks like a tenfold deterioration.
There is no basis for reading it that way.
Nothing in the feed separates more incidents from more reporting. A company that logs minor degradations and one that logs only full outages look very different by count, and the second looks better. The same distortion applies to one company across time.
2023 has two entries. Whether only two things went wrong that year, or only two were written up, cannot be determined.
The count is disclosure plus incidents, added together. They cannot be separated here, so they are left unseparated.What the feed does not carry
The limits first, because without them the 45 entries are unusable.
No severity. All 45 come back asunknown. A brief slowdown and a total outage sit side by side as one entry each.
No resolution time on 23 of them. Half the entries do not say when they ended, so total downtime cannot be summed.
Because of those two, this article does not compute an uptime figure. How many times something broke is countable; how long it stayed broken is what matters to a buyer, and that is not available from what is published.
The figures stop where the evidence stops.
Publishing it at all is still the difference
Having listed the gaps, it is worth remembering the comparison.
For the other eight, even this much cannot be established from outside. UptimeRobot publishes a feed and its own robots.txt closes the door on it. Cronitor renders only via JavaScript, and runs its status page on Hyperping, a competitor. The rest have no machine-readable exit at all.
Forty-five entries without severity or resolution times are not a complete record. But a record reaching back three and a half years, retrievable in a single request today, existed at one company out of nine.
And incident history, unlike pricing, cannot be recovered later. Pricing pages sit in the Internet Archive going back years; status.betterstack.com/feed.rss has no capture there at all. Nobody saved it. The day a company folds its feed, its past goes with it.
Pricing has not moved since tracking began
The pricing page is saved too. It is currently built per capability — you add what you use.
| Item | Monthly |
|---|---|
| Uptime monitoring | $25 |
| Heartbeats / cron monitoring | $20 |
| Status pages | $15 |
| Reporting & analytics | $5 |
| Security | $5 |
| Bundles | $25 |
| Call routing | $250 |
No price change has been recorded since this cat started saving the page. The tracking window is short, though, so this is not "a company that does not raise prices". It is only "nothing has moved since the day we started looking".
A year from now there will be more to say. A price history can only be built forward from the day you begin keeping it.
What could not be established
Beyond the above:
Whether incidents exist that never reached the feed cannot be checked from outside. The 45 counted here are the incidents Better Stack published, not the incidents that occurred.
The blast radius of each is unknown. Whether only Telemetry was slow or monitoring itself stopped can be guessed from the titles but not confirmed.
No count comparison against other vendors is offered, because there is nothing to compare against.
This article carries an affiliate link
The position, stated plainly.
This site is in Better Stack's affiliate programme. The link below is tracked, and a signup through it pays this site.
The finding that Better Stack was the only one of nine publishing a machine-readable history predates that arrangement, and the article reporting it was published before it. The order is not reversed.
With that said, this article does not recommend Better Stack. With no severity and no resolution times published, there is no material for claiming it is more reliable than anyone else. What can be claimed is narrower: it is the only one of the nine that publishes its record in a form you can check.
Whether that is worth anything is the reader's call, not this cat's.
Sources
The incident history was read directly from the RSS feed published by Better Stack's own status page — counting the entries and reading the start time, resolution time and severity fields as they came.
- Better Stack Status
- Incident feed (45 entries as retrieved in August 2026)
- Better Stack pricing
The nine-vendor survey is a separate article.
Only what the vendor publishes itself is used. No user reviews or forum posts.
Ad: Better Stack