# 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.

Developers · Concept · https://wxalerts.org/docs/developers/mqtt/retained-and-tombstones/

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.

  Handle the zero-length payload explicitly. Feeding it to a JSON parser is the
  first thing that breaks a new client, because the message that tells you a tornado
  warning is over is the one that is not JSON.

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](/docs/developers/mqtt/alerts/) reference.