How to track vendor changelogs and status pages in one place
Most vendors already publish both streams as feeds, so the one-place version of this is a feed reader with two URLs per vendor in it: the status page’s incident feed and the changelog’s RSS. A status page hosted on Atlassian Statuspage serves its incident history at /history.atom — fetched with no credentials on 5 August 2026, both https://www.githubstatus.com/history.atom and https://www.cloudflarestatus.com/history.atom returned HTTP 200 with content type application/atom+xml and 25 entries each. The three options below exist because building that list by hand has a real cost, and because the path convention is not universal. Every fact on this page was checked against a live response or a primary source on 5 August 2026, and each is linked at the bottom.
1. Status-page Atom feeds — the direct answer, and it is free
Vendors that host their status page on Atlassian Statuspage expose the incident history as an Atom feed at the /history.atom path on the status hostname, and reading it needs no account, no token and no relationship with the vendor. Fetched unauthenticated on 5 August 2026, https://www.githubstatus.com/history.atom returned HTTP 200, content type application/atom+xml, and a feed titled “GitHub Status - Incident History” carrying 25 entries; the same request against https://www.cloudflarestatus.com/history.atom returned HTTP 200, the same content type, and a feed titled “Cloudflare Status - Incident History”, also with 25 entries. Point a reader at those URLs and platform incidents arrive in the same place as everything else that reader watches.
What an incident feed carries is worth knowing before treating it as an alerting channel. The history feed is the record of incidents and scheduled maintenance a vendor has already posted, so a reader polling every fifteen minutes learns about an outage roughly fifteen minutes after the vendor writes it up, not the moment a service degrades. For a wall-clock alert on a service a business depends on, an external uptime check against the service itself is the tool; the incident feed is the tool for knowing what the vendor says happened and when they closed it.
2. The /history.atom path is a convention, not a standard
A script that appends /history.atom to every vendor’s status hostname will silently come back empty for a meaningful share of them, because the path belongs to one hosting product rather than to status pages in general. Fetched on 5 August 2026, https://status.openai.com/history.rss returned HTTP 200 with content type application/rss+xml and an RSS 2.0 document titled “OpenAI status”, described in its own channel as “OpenAI status page updates” — a different path and a different feed format from the two Atom feeds above. Vendors who build their own status page, or host it on something other than Statuspage, choose their own URL and their own syndication format.
The practical consequence is that the list has to be built once, by hand, per vendor. Open each vendor’s status page, look for the subscribe or RSS control, and record the feed URL it gives; where none is offered, try /history.atom and /history.rss before concluding there is no feed. That list then stays valid for years, which is why the hand-built approach beats the aggregators for anyone tracking a stable set of a dozen vendors — and why it loses badly for anyone tracking a hundred.
3. Changelog RSS — the half most status-page tools do not cover
A changelog answers a different question from a status page: not “is it broken” but “what changed underneath us”, which is the one that breaks a build on a Tuesday morning with no incident anywhere. Vendor changelogs are usually published on a blog platform and syndicate accordingly. Fetched unauthenticated on 5 August 2026, https://github.blog/changelog/feed/ returned HTTP 200 with content type application/rss+xml and a channel titled “Archive: 2026 - GitHub Changelog” carrying 10 items, including entries on customising code scanning default setup at scale and the retirement of the Copilot Billing Preview app.
One limit applies to changelog RSS the same way it applies to a GitHub repository’s releases.atom: the feed is a window, not an archive. The GitHub changelog feed read on 5 August 2026 carried 10 items, so a reader that polls less often than a busy vendor ships will miss entries in the gap and never know it did. Poll frequently enough for the vendor’s publishing rate, or accept that the feed is a notification channel rather than a searchable record and keep the record somewhere else.
4. StatusGator — the aggregator built for the status-page half
StatusGator watches other people’s status pages and normalises them into one view, which removes the find-the-feed-URL step this page opens with. Its plans page, read on 7 August 2026, describes the service as “a status page aggregator and independent monitoring service tracking the availability of more than 9,960 services since 2015”, and lists delivery through Slack, Discord, Microsoft Teams, Google Chat, Webex, email and SMS, plus PagerDuty, Opsgenie, Zendesk, Freshdesk, webhooks and a REST API. For a team that already lives in one of those channels, that is a shorter path than a feed reader.
The plan shape read on 7 August 2026 is where the decision usually gets made. The free plan covers 3 monitors, 1 board, 1 admin user and 10 notifications per month, with “No credit card required” for trial access. Above it, Starter covers 25 monitors at $79 per month billed monthly or $72 per month billed annually; Team covers 75 monitors at $149 monthly or $137 annually; Corporate covers 150 monitors at $299 monthly or $274 annually; Enterprise is quoted. Note what none of those tiers buy: StatusGator aggregates status pages, so vendor changelogs and package releases are outside what it watches, and the changelog half of this question still needs a second tool. Prices change without notice — check the plans page rather than this one before spending.
5. The Standup — one wire, and an honest limit
The Standup puts vendor changelogs and platform outages on the same feed as tagged releases and reviewed advisories, in one daily email, and it is free to read in full. What it does not do is take a list of vendors: there is no per-reader watch list, no way to add a company and get its incidents, and no alert scoped to one vendor’s status page. Every reader gets the same wire in the same order. Anyone whose requirement is “tell me about these eleven vendors and nothing else” should build the feed list in section 1 or use an aggregator, both of which do that properly.
The gap a shared wire fills is the vendor nobody thought to add. A hand-built feed list covers what someone remembered on the day they built it, and an aggregator covers the services someone selected from a catalogue; neither reports the outage at a platform a service quietly started depending on last quarter, or the changelog entry from a vendor two layers down the stack. Most working setups end up as two things rather than one: a feed list or an aggregator for the vendors that matter by name, and a digest for the surface area around them.
The four options compared
Each row states what the approach covers, whether a per-vendor list is possible, what setting it up involves, and what it costs, as verified on 5 August 2026.
Approach | What it covers | Per-vendor list? | Setup | Cost |
|---|---|---|---|---|
Status-page Atom feeds | Incidents and maintenance, from the vendor itself | Yes — one feed URL per vendor | Find each feed URL by hand | Free, but you supply the reader |
Changelog RSS feeds | What a vendor shipped, in the vendor’s own words | Yes — one feed URL per vendor | Find each feed URL by hand | Free, but you supply the reader |
StatusGator | Status pages only — no changelogs, no releases | Yes — picked from its own catalogue | Account, then choose services | Free for 3; paid plans from $79/mo |
The Standup | Releases, changelogs, advisories and outages on one wire | No — there is no per-reader list | An email address | Free |
Which one to pick
For a stable set of roughly a dozen vendors, the feed list wins and costs nothing: two URLs per vendor in a reader that already exists, built once in an afternoon and valid for years. For a catalogue of dozens of services, or for a team that wants incidents landing in Slack rather than a reader, an aggregator earns its price by removing the per-vendor discovery step — StatusGator is the one checked here, and its free tier’s 3 monitors and 10 notifications per month make it an evaluation tier rather than a working one. Neither covers changelogs and status pages with a single tool: the feed list does, an aggregator does not.
Releases and security advisories are adjacent questions with their own answers on this site. How to get an email when a GitHub repo publishes a release compares GitHub’s custom watch, releases.atom, Dependabot, NewReleases.io and this wire. How to get an alert when a dependency has a new security advisory compares Dependabot, the GitHub Advisory Database API, OSV.dev, npm audit and this wire. Changelogs, releases and advisories are three streams, and the tools that cover one rarely cover the others. The best developer news digest emails for releases and outages is the fourth comparison and the one that covers none of the three properly — TLDR, Console.dev, Changelog News and daily.dev are edited, so a vendor outage reaches them only when it is the story of the day.
Common questions
Do status pages have RSS or Atom feeds?
Most do, and on Atlassian Statuspage the incident history is served at /history.atom on the status hostname. Fetched with no credentials on 5 August 2026, https://www.githubstatus.com/history.atom and https://www.cloudflarestatus.com/history.atom both returned HTTP 200 with content type application/atom+xml, each carrying 25 entries. Vendors not on Statuspage choose their own path and format — https://status.openai.com/history.rss returned HTTP 200 with content type application/rss+xml on the same date — so the feed URL has to be confirmed per vendor rather than assumed.
What is the GitHub status page RSS feed URL?
GitHub’s incident history feed is https://www.githubstatus.com/history.atom, an Atom feed rather than RSS. Fetched unauthenticated on 5 August 2026 it returned HTTP 200 with content type application/atom+xml and a feed titled “GitHub Status - Incident History” carrying 25 entries. GitHub’s changelog is a separate stream at a separate URL: https://github.blog/changelog/feed/, which returned HTTP 200 with content type application/rss+xml and 10 items on the same date. Following GitHub properly means subscribing to both.
Can one tool track both changelogs and status pages?
A feed reader can, because both streams are published as feeds and a reader does not care which is which — that is the cheapest single-tool answer, at the cost of finding each URL by hand. Status-page aggregators generally cannot: StatusGator describes itself on its plans page, read 7 August 2026, as “a status page aggregator and independent monitoring service”, and its monitors are status pages rather than changelogs. A daily wire such as The Standup carries both kinds on one feed, but as a shared editorial stream rather than a list a reader controls.
How many entries does a status page feed hold?
The two Statuspage-hosted history feeds checked on 5 August 2026 each carried 25 entries: https://www.githubstatus.com/history.atom and https://www.cloudflarestatus.com/history.atom both returned exactly that many. A window of 25 incidents is generous for a vendor that has a bad week twice a year and short for one that posts maintenance notices weekly, so a reader polling infrequently can miss entries at a noisy vendor. Treat the feed as a notification channel, and keep anything worth searching later in a store that does not roll off.
Is StatusGator free?
There is a free plan, and its limits decide whether it is usable. The StatusGator plans page read on 7 August 2026 lists the free tier as 3 monitors, 1 board, 1 admin user, 100 status page subscribers and 10 notifications per month, with “No credit card required” for trial access. Paid plans on the same page start at Starter — 25 monitors at $79 per month billed monthly, or $72 per month billed annually — and rise through Team and Corporate to a quoted Enterprise tier. Prices change; check the plans page before deciding on one.
Sources
Every claim above traces to one of these, each fetched on 5 August 2026. Four are live HTTP responses rather than documentation, because what a URL serves is the claim being made. Prices and product behaviour change without notice — check the source rather than this page if a decision rests on it.
www.githubstatus.com/history.atom — Fetched unauthenticated 5 August 2026: HTTP 200, content type application/atom+xml, 25 entries, feed title “GitHub Status - Incident History”.
www.cloudflarestatus.com/history.atom — Fetched unauthenticated 5 August 2026: HTTP 200, content type application/atom+xml, 25 entries, feed title “Cloudflare Status - Incident History”.
status.openai.com/history.rss — Fetched unauthenticated 5 August 2026: HTTP 200, content type application/rss+xml, RSS 2.0 — the counter-example to the .atom path convention.
github.blog/changelog/feed/ — Fetched unauthenticated 5 August 2026: HTTP 200, content type application/rss+xml, 10 items, channel title “Archive: 2026 - GitHub Changelog”.
StatusGator plans — Plan names, monitor counts and prices. Fetched 5 August 2026.
Where to go next
What the wire covers is the full list of the nine kinds on the feed and how the daily email works. Releases and changelogs is the archive filtered to what vendors shipped. Advisories and outages is the reviewed-CVE and live-incident view. The wire is the current feed, newest first.