Aglet

Triage notification delivery retry visibility before changing status copy

A notification can exist while its preferred channel is queued, retried, delayed, or failed. Triage the status promise before exposing more technical detail. Capture event state, channel attempt, retry, in-app record, and available action so a person can tell what is known.

Establish what is happening

  1. Capture delivery states

    Record event creation, accepted, queued, delivered, failed, retry, timestamp, channel, in-app state, and user action. Include a successful and a uncertain path. Keep provider or platform confirmation separate from local event existence.

  2. Compare what is visible

    Ask what status a person sees and whether it describes event, channel, or both. Compare “sent,” “available,” “waiting,” and “failed” meanings. A durable in-app record can be truthful even when external delivery is unconfirmed.

  3. Set a status boundary

    State which transitions are user-visible, what recovery exists, and when uncertainty expires or changes. Preserve an operational control. Stop when another reviewer can distinguish event state from delivery confirmation without internal jargon. Record the last local state before any retry was shown.

What to carry forward

The triage output is a delivery vocabulary with event, channel, retry, timestamp, and user-visible state. Stop when local existence and external confirmation are distinguishable. If confirmation is unavailable, use cautious status and route the evidence gap.

Technical background: Android developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow