Let anyone follow your incident history in a feed reader, without giving you an email address.
Every status page can serve its incident history as an RSS feed and an Atom feed. Feed readers, Slack's built-in RSS app, internal dashboards, and vendor status aggregators poll them directly. Nobody subscribes, so there is no list to manage and nothing to unsubscribe from.
Feeds are useful when:
Both feeds live at fixed paths on your status page domain:
| Format | URL | Content type |
|---|---|---|
| RSS 2.0 | /history.rss | application/rss+xml |
| Atom 1.0 | /history.atom | application/atom+xml |
On a custom domain that gives https://status.acme.com/history.rss. The Hyperping-hosted slug works too: https://acme.hyperping.app/history.rss.
These are the same paths statuspage.io uses, so feed readers and integrations pointed at your old page keep working once the domain points to Hyperping. See the import guide for the rest of the migration.
curl https://meta.hyperping.app/history.rssGo to Status Pages, pick your page, then open the Notifications category.
Turn on the RSS & Atom feeds toggle. Both feed URLs appear underneath, with a copy button on each.
Hit Publish. The feeds are live straight away.
New status pages have feeds on by default. Pages created before feeds shipped keep them off until you flip the toggle, so an older page returns a 404 on both URLs until then.
Each feed carries the 25 most recent incidents and maintenance windows, sorted by latest activity. An incident that gets a new update moves back to the top, so a reader surfaces it again instead of leaving it buried under newer entries.
Every entry holds:
<item>
<title>Elevated API error rates</title>
<link>https://status.acme.com/history/inc_8Kd2mQ</link>
<guid isPermaLink="true">https://status.acme.com/history/inc_8Kd2mQ</guid>
<pubDate>Mon, 20 Jul 2026 15:41:00 GMT</pubDate>
<description><![CDATA[
<p><small>Jul 20, 17:03 UTC</small><br/><strong>Resolved</strong> - Back to normal.</p>
<p><small>Jul 20, 16:12 UTC</small><br/><strong>Identified</strong> - A bad gateway deploy.</p>
<p><small>Affected services: API, Dashboard</small></p>
]]></description>
</item>Feeds cover incident history only. For the current up or down state of your services, use the status.json endpoint instead.
On a multilingual status page the feed is served in the page's default language, including the update labels. Add a lang parameter to get another one:
https://status.acme.com/history.rss?lang=fr
The value has to be one of the languages enabled on the page. Anything else falls back to the default, so a reader never gets an empty feed from a typo.
While feeds are on, your status page carries <link rel="alternate"> tags for both formats in its head. Point a feed reader at https://status.acme.com and it finds the feeds on its own, no exact URL needed.
Feeds are cached for 5 minutes at the edge, and the cache is cleared the moment you publish an incident update or save your page settings. In practice the delay your readers see comes from their own polling interval, which is usually somewhere between 15 and 60 minutes depending on the reader.
On a protected page, both feed URLs answer 401 unless the request carries a valid session. Feed readers cannot sign in, so treat feeds as a public-page feature. The autodiscovery tags are left out of protected pages for the same reason.
Feeds are opt-in per page. Open the Notifications category of your status page settings and turn on RSS & Atom feeds. Pages created before the feature shipped default to off, which is the usual cause on an older status page.
The page is password or SSO protected. Feeds only serve anonymous requests on public pages.
The page has no incident or maintenance history yet, or its entries have no valid date. Feeds carry history, not live status: a page where everything is operational and nothing ever broke has an empty feed, and that is correct.
Feeds are capped at 25 entries. Older incidents stay on the status page and in the incident calendar, they just roll off the feed.
Publishing an update clears our cache immediately, so the delay is on the reader's side. Most feed readers poll every 15 to 60 minutes and many let you refresh a feed by hand. Fetching the URL with curl tells you straight away whether the update is live on our end.