TTL tells the push service how many seconds to keep a message if the browser is offline, and it is required. Urgency marks priority from very-low to high and defaults to normal. Set a short TTL on time-sensitive alerts so a stale warning never arrives hours late.
Definition
Both are HTTP request headers your application server sends to a push service under RFC 8030, Generic Event Delivery Using HTTP Push.
TTL
The application server must include TTL, a number of seconds. A push service must respond with 400 if it is missing. The service may keep the message for less time than requested and reports the actual value, which must not exceed what you asked for. After TTL expires, it must not deliver the message. A TTL of zero means deliver only if the browser is available right then, otherwise expire.
Why this matters for security: a login approval, a one-time code notification or a fraud alert is wrong or even dangerous if it arrives hours late. A user who approves a stale prompt may approve the wrong thing. Match TTL to the life of the event.
Urgency
| Value | Typical use |
|---|---|
| very-low | Newsletters, background updates |
| low | Non-time-critical updates |
| normal | Default when the header is absent |
| high | Time-sensitive alerts such as security events |
The push service must not forward Urgency to the browser. The browser can say what level it wants while monitoring, and the service must not deliver messages below it. Sending several Urgency values in one request produces a 400.
Delivery receipts and 410
A 201 response to a push request does not mean the message reached the browser. Receipts exist only if you ask for them. If you requested one and the browser never acknowledged the message, the service may send a 410 Gone failure on the receipt subscription. Do not confuse this with a dead subscription.
Suggested defaults
| Message type | TTL idea | Urgency |
|---|---|---|
| Login approval or code | Minutes, no longer than the code's life | high |
| Security alert | Hours | high |
| Order update | A day or so | normal |
| Marketing | As long as the offer is valid | low or very-low |
These are starting points to adjust, not rules from the RFC.
Steps
- Set TTL explicitly on every send, per message type.
- Match TTL to the validity of any code or approval in the message.
- Use high urgency only for events that justify waking a device.
- Do not rely on a 201 as proof of delivery; track opens or acknowledgments in your app.
- Pair with subscription handling rules so dead subscriptions are removed.
Where Safeguard fits
Safeguard's dependency scanning checks the push libraries you use against known advisories, and its policies help enforce review of notification code paths. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is TTL optional?
No. RFC 8030 says the application server must include it, and the push service must return 400 if it is missing.
Does a 201 mean the user saw it?
No. It means the push service accepted the request, not that the browser got the message.
Sources
Last reviewed: 19 October 2026.
