Stop a delayed push from delivering an expired promise

Identify the last useful delivery moment

Firebase describes message lifetime as the period during which its service stores and attempts delivery, with platform-specific settings for Android, web and Apple delivery. A returned message identifier indicates provider acceptance rather than confirmed device delivery. These distinctions are documented behavior, not an end-to-end timing guarantee.

Write the point after which the message would become misleading or useless. An event starting tonight may require a much shorter useful window than an evergreen announcement. Separate the scheduled send time from the offer's authoritative expiry and state the timezone explicitly. The objective is not to maximize the number of eventually delivered messages; it is to avoid presenting a time-sensitive invitation after its meaning has expired.

Translate the commercial boundary into the actual provider setting

Ask the implementation owner how the relevant platform expresses expiry: a relative storage duration, an absolute expiration or another supported field. Have them check units and defaults rather than copying one field across operating systems. A duration computed when a campaign is created can be wrong when the actual send occurs hours later.

Use synthetic timestamps to test a normal send, a late batch and a retry near expiry. If no useful window remains, the optional promotion should not be newly sent merely to complete the planned audience count. Firebase documents that a zero lifetime discards messages that cannot be delivered immediately; that is a loss-tolerance decision, not a way to force delivery. Do not raise priority or choose another channel simply to defeat a user's controls.

Distinguish storage expiry from displayed-content behavior

Once a notification has reached the device and is visible, the provider's storage lifetime is not a promise that the operating system will remove that displayed item at the same time. Ask the app owner which supported local removal or update behavior exists, if the campaign requires it, and test the actual implementation rather than assuming a remote expiry can recall content.

Keep the wording useful when read later. Prefer an explicit event date to an ambiguous tonight when delayed reading is plausible. On tap, have the destination obtain current offer state through its normal authorized route. It should explain an ended offer and provide an appropriate next step, not silently apply a different price or imply that tapping the old notification reserved availability. A short storage window cannot replace a truthful destination.

Rehearse reconnection on both sides of the boundary

Create controlled cases where a test device reconnects before expiry, after expiry and after a notification was already displayed. Record provider acceptance, any observed arrival, displayed state and destination response separately. Include a delayed sender or retry queue so the test covers more than network loss at the device.

If the observed behavior differs from the plan, identify which clock or component caused the mismatch. The sender may have used a stale duration, the provider may have applied another platform field, or the user may simply have opened an earlier displayed notification. Resolve the specific issue with the owning team. Preserve the tested scope and avoid claiming that all offline devices behave identically. The release decision should describe the useful delivery boundary and the safe late-reading path.

Make the reasoning concrete.

A fictional arts venue sends a last-minute ticket offer at noon for a performance that evening. A test phone reconnects the next morning, while another phone received the message promptly but opens it a day later.

The venue distinguishes pending storage from an already visible notification and tests both. It does not describe the configured lifetime as a guaranteed recall.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Meaning

   After what exact moment would a newly delivered message no longer be useful?

2. Field

   Which platform setting expresses the allowed storage interval or expiry?

3. Delay

   Is the value recomputed correctly for late sends and retries?

4. Display

   What is known about content already shown on the device?

5. Tap

   How does the destination explain that the offer has ended?

Watch for the wrong conclusion.

• Treating provider acceptance as device delivery.
• Assuming TTL removes an already displayed notification.
• Reusing a duration calculated long before the actual send.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Firebase: Set the lifespan of a message →Primary platform documentation · Supports: Supports provider storage lifetime, platform-specific expiry, acceptance-versus-delivery and zero-lifetime discard behavior; commercial and displayed-content checks are editorial.