Embeds, badges and feeds

Put your status somewhere other than the status page — a badge in your README, a feed in a reader, or live data in your own app.

Not everyone will visit your status page. These surfaces bring the status to them.

Status badge

An SVG badge showing current status, suitable for a README or a docs site:

https://api.glowo.dev/api/v1/status-pages/<slug>/badge.svg

In Markdown:

[![Status](https://api.glowo.dev/api/v1/status-pages/<slug>/badge.svg)](https://status.yourcompany.com)

Link the badge to your status page — a badge that says something is wrong is only useful if people can click through to find out what.

Feeds

Atom and RSS feeds of your incidents, for people who would rather subscribe in a reader than by email:

https://api.glowo.dev/api/v1/status-pages/<slug>/feed.atom
https://api.glowo.dev/api/v1/status-pages/<slug>/feed.rss

Both are public and need no credentials. Feeds are a good option for technical audiences who dislike marketing-adjacent email.

Public JSON

Read-only JSON for any published page, unauthenticated:

Use these to show status inside your own product — a banner in your app during an outage does more to reduce support volume than any status page on its own.

Embed API

The /api/v1/embed/* endpoints serve the same shape of data authenticated by a publishable key, which is designed to be safe in client-side code:

The key can be passed as a bearer token or as a ?token= query parameter, and it can be regenerated if it leaks.

/events is a Server-Sent Events stream, so an embedded widget updates without polling.

Caching

Public status endpoints are cached briefly. Status data tolerates a few seconds of staleness, and caching is what keeps the page up when a real outage sends everyone to it at once.

Build clients that poll politely, or use the SSE stream instead of a tight poll loop.