Useful errors: known status and next action
An error message is not only a report that something went wrong. It should say what the system knows, what it cannot know, and which single action helps now, without encouraging blind retries.
Separate known and uncertain status
“Sending failed” differs from “we do not know whether it arrived”. The first is a known outcome; the second calls for caution to avoid duplicates.
Show the time of the last update and the observable fact. Do not turn a timeout into certainty about a person’s condition or safety.
Give the network a next step
For no network, say whether content stayed on the device, is queued, or has an unknown status. Suggest checking the connection or using the agreed channel.
A confirmed command may be saved on the device and retried in the background when the product documents that behaviour. For a new send, check status first; an uncertain result should not create a duplicate.
Help with permissions
A denied permission should name the affected feature and why it matters. Explain where to change it without promising that permission alone will solve every issue.
Offer an alternative when location or notifications are unavailable. The path should not block a manual call or message.
Handle recipients and data
If a recipient is missing, disabled, or unreachable, identify that entry and say what remains available. Do not restart the whole send without confirmation.
Show recipients, shared data, and the consequence of the next action. A vague error makes people guess and can expose information to the wrong contact.
Recover without losing work
Keep a draft only if the product says it does, and explain how to recover or delete it. “Retry” and “Edit” must do different things and use consistent labels.
After an error, return focus to the message and keep the text near the field or action that can fix it. Do not send people to the top of the page.
Test the next action
Try slow and absent networks, denied permission, removed recipient, and uncertain response. Ask users to name what is known and which button they would choose.
Check language, zoom, screen reader, and keyboard too. In immediate danger, an app error does not suspend the local emergency number.
Frequently asked questions
Does a timeout mean the message did not arrive?
No. It means the app received no confirmation in time; the result may remain uncertain.
Should I press “Retry” immediately?
Only when the product documents an idempotent command or shows that the first attempt did not start. With an uncertain status, check the outcome or use the agreed channel.
Does granting a permission always fix the error?
No. It may enable one feature, while network, recipients, and service availability remain separate conditions.
Sources consulted
Technical and safety information was checked against the following official sources.
Editorial note: this guide applies W3C guidance and the GOV.UK error-message component to a coordination app. Sources were checked on 8 September 2026; behaviour depends on the product.
LOOK AT STATUS
Every error should say what to do next
Test network, permissions, recipients, and uncertain status without creating duplicate sends.
Explore My Safe CircleThis guide covers interface errors and recovery; it does not replace emergency services. For immediate danger, call the relevant local number.