Community. Driven. Weather. Data. | Always Ad-Free | Developer FriendlyChecking statusDiscord
Become a supporter
Sign in

Retained alerts, and tombstones

Why the alerts feed keeps every live hazard on the broker, and how an empty message tells you one has ended.


A live hazard is retained, so subscribing delivers it immediately.

A hazard ends by way of a tombstone: an empty payload, retained, on the topic it lived on. Drop the alert when one arrives.

Just before the tombstone, the ended hazard is published once more on every one of its topics, not retained, with status set to expired or cancelled. A client that is connected at the time sees why the hazard ended; one that connects later sees nothing, because the retained copy is gone.

This matters more than it sounds. Expiring alerts on local clock arithmetic means a canceled warning hangs around until its original end time, and a client whose clock has drifted gets it wrong in both directions. Trust status and the tombstones over anything you compute yourself.

The topics, payload and retention figures are in the MQTT alerts feed reference.

View this page as Markdown

May we use Microsoft Clarity to see how pages are used (clicks, scrolling and replays of a visit, with anything you type hidden), plus a random ID linking that to crash reports? Only to find bugs and confusing screens. Never advertising, never sold.