Practical guide

Write error messages that help people recover

Explain whether work was saved, what is uncertain and what the user can safely do next.

Last materially reviewed 2026-09-18

Quick answerA useful error message describes the state of the work, not just the fact that something went wrong.
What to know

Diagnose the cause: invalid input or failed work

A missing required field can usually be corrected before anything is submitted. A server error after submission is different: the request may have reached the service. Give those situations different messages. Avoid a single red banner that tells everybody to try again. The wording should reflect what the application actually knows, not what would make the interface look confident. Preserve entered information when it is safe to do so.

What to know

Keep unknown outcomes explicitly unknown

If a connection closes after a consequential action, do not announce failure unless you have evidence that nothing happened. Show the original request reference and a supported way to check its status. For harmless local tasks, a retry may be straightforward; for payments, notifications or paid generation it can create duplicates. The recovery behavior must match the operation, not just reuse a generic retry button.

What to know

Explain the next action in ordinary language

Prefer “Your request is still being checked; do not submit it again yet” over an unexplained technical code. Where a code helps support investigate, show it separately without exposing secrets. If a session expires, explain that signing in restores access, not that all work was lost. Never imply that refreshing a page will undo a write or refund a charge when the system has not established that.

What to know

Test the error message and recovery together

Use a controlled, non-chargeable test response to simulate delayed, denied and failed outcomes. Check that repeated clicks cannot start conflicting actions and that returning to the page preserves the original identity. Ask a reviewer what they would do after reading the message. If their interpretation would cause an unsafe repeat, change the design. Clear language and reliable state handling need to be verified as one experience.

Continue when useful

Next: Prevent a double click from becoming duplicate work

Design submission feedback around one identifiable request.

Open Prevent a double click from becoming duplicate work →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Overskill API error guidance — Merchant documentation · overskill.com · Merchant-controlled · checked 2026-09-18
  2. MDN accessibility introduction — Reference · developer.mozilla.org · Publisher independence not verified · checked 2026-09-18