--- title: "Public platform-news Atom feed (unauthenticated)" method: GET path: "/feed.xml" --- # Public platform-news Atom feed (unauthenticated) `GET /feed.xml` ## Request - Base URL: `https://api.uptimemonitoring.com` - URL: `https://api.uptimemonitoring.com/feed.xml` - Auth: none required Public Atom XML feed rendering currently active platform announcements from the shared `announcements` table. No `Authorization` header is required. The feed contains at most 50 entries, ordered descending by `published_at` (with a stable secondary `id` tiebreaker). Active means `published_at <= now()` AND (`expires_at IS NULL` OR `expires_at > now()`). Empty active sets still return a valid Atom envelope with zero `` rows so aggregator-cache content hashes stay stable. Cache-Control is `public, max-age=300` — Cloudflare in front of the API will respect the hint. Announcements are not time-critical, so a 5-minute window is acceptable. `` semantics: the feed-level `` is a best-effort change marker, not a linearizable version counter. It is the GREATEST of four signals — an edit to any announcement (including one that unpublishes a row by pushing `published_at` into the future), a scheduled announcement crossing into visibility, an active announcement crossing into expiry, or a hard delete — and it never exceeds the current time. Writes to *different* announcement rows take no shared lock, so two concurrent edits can commit in an order where the marker does not advance past a value a reader already observed even though a new change became visible in that window. Treat `` as a "poll again soon" hint, not a guarantee that an unchanged value means nothing changed since your last read. Per-entry `` is the later of that announcement's last edit and its `published_at`, clamped so it never exceeds the current time — a just-published scheduled announcement reads `updated == published` rather than updated-before-published, and a row whose last-edit timestamp is ahead of real time (clock skew, or accumulated strict-advance drift) reads the current time instead of that future value. Timestamps use full sub-second precision (RFC 3339 with fractional seconds) so edits within the same wall-clock second still render distinct values. ## Response `200` Atom feed ## Other responses - `500`: Database error rendering the feed --- [API](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api.md) · [All operations](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/llms.txt) · [OpenAPI document](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/revisions/ddcb2a8bc70f?raw)