Your error message could be making promises your product can’t keep

Make sure ‘try again’ is safe advice before you put it in an error message. If you cannot establish that, ask the service owner before approving the line.

Take a hypothetical application form. Someone fills it in, presses submit and gets a timeout. The message you are about to approve says, ‘Your application was not received. Try again.’

That wording tells the person their application did not arrive and another attempt is safe. The team in this example has not established either. It also does not know whether the answers are saved or whether submitting again could create a duplicate.

Check what you are asking the user to fix

Before telling someone to check their details, establish that their details need correcting. In the hypothetical form, the timeout has left the team unsure what happened. Changing an answer may have nothing to do with getting the application through.

GOV.UK’s error-message guidance keeps input errors separate from eligibility, permission and service problems the person cannot fix by editing a field. Use that distinction when deciding what your message should ask them to do:

If this is the problem	Check this before writing the next step
Information is missing or unusable	Which answer needs attention and what correction the service accepts
Eligibility or permission prevents progress	What decision has been made and which explanation or alternative you can offer
The service is unavailable	What you know about availability and whether another route exists
The result of the attempt is unknown	How someone can check the result, or what makes another attempt safe

There is a specific accessibility requirement for input correction. Under WCAG’s Error Suggestion criterion, known correction suggestions must be provided for automatically detected input errors, unless that would jeopardise security or the purpose of the content. The requirement concerns input errors; a service failure may leave the person with nothing they can correct.

Find out what the timeout leaves unknown

Before approving ‘Your application was not received’, ask what would let you confirm that statement. The operation could have succeeded even though the software sending the request never received its response.

Stripe’s error-handling documentation describes this possibility in its own system. After some connection failures, the software making a request cannot know whether Stripe received or executed it. That is a concrete reason to check the behaviour of your form. It does not establish what happened to the hypothetical application.

The same uncertainty affects ‘try again’. If your service can handle repeated attempts without creating a second application, another submission may be safe. That protection needs to be established for the route you are recommending.

The HTTP specification places conditions on automatic retries for operations that might otherwise be repeated. It governs software. For a message asking a person to repeat an action, I would apply the same concern by checking what the service does with that repeat.

You may be able to establish safe resubmission while the original result remains unknown.

Take the unanswered promise to the service owner

Give the service owner the line you are being asked to approve and identify the facts it depends on. For the hypothetical application, I would ask:

• Can the person or service team check whether the application arrived?
• What happened to the entered answers?
• Is another submission safe through this route?
• What help or alternative is available, and what can it do?

The answer may be a description of something the service already does. If the owner confirms a usable way to check receipt, you can explain that route. If no recovery route exists, the owner has a service problem to resolve before you can promise one in the copy.

Record the specific promise that needs an answer. For this example, that includes whether you can safely invite another submission.

Once the facts and next action are established, use your existing authority to make the wording clear. A disagreement about a voice rule has its own decision about scope and authority.

You can still communicate useful facts while an unknown is investigated. If the team knows the service is unavailable, it can say so without a precise technical diagnosis. Keep the unresolved promise separate from the information you can already support.

Write a next step the service can support

‘We have saved your answers’ needs confirmation of what was saved and how the person can resume. A return time needs an agreed basis too. If you add a contact route, check that the team receiving the enquiry can help with this problem.

A common failure message can be appropriate. GOV.UK’s service-problem pattern recommends a shared page for unexpected problems. It includes information about entered answers and useful available contact or alternative routes. The separate service-unavailable pattern includes a return time when that is known. These are recommendations for service design; they do not provide a measured completion improvement for your form.

Use what your service can establish. A pattern’s example retention period cannot tell you how long your product keeps answers. If there is no immediate alternative, explain that limit rather than add a route nobody can use.

You may also need to withhold a detail for security. OWASP’s authentication guidance recommends generic responses to avoid revealing whether an account exists. In that setting, consider which safe next step you can offer without disclosing the sensitive distinction.

Check the notice in the interface, including with relevant assistive technology. WCAG’s Status Messages criterion covers status information presented without a change of context. It requires that information to be available programmatically so assistive technology can present it without receiving focus. The treatment depends on the interaction; a copy review alone cannot establish that it works.

Follow the route the message offers too. Check that the person can use its link or control and reach somewhere that supports the stated action.

Watch someone try to recover

Put the message in front of likely users at the point of the failed interaction. Ask what they believe happened and what they would do next. Watch whether they can use the offered route. Check separately that the service does what the words describe.

A small qualitative session can expose a misunderstanding worth investigating. It cannot tell you how common that problem is across your audience or establish an improvement in completion.

Adding instructions is something to test. In a 2026 course-registration study, Katie Heberlein and colleagues assigned 44 university students to original messages or versions with recovery instructions. The simulation found no statistically significant difference between groups in errors or time. The small sample and screenshot-based tasks limit what that tells you about another service. It does not show that the designs were equivalent or that instructions are useless.

In Park, MacDonald and Khoo’s 2012 study, 30 students received neutral, apologetic or blaming messages during library-search tasks. Those receiving apologetic messages reported less frustration and better perceived usability than those receiving neutral messages. The study did not measure successful recovery, and the messages varied in more than the presence of an apology.

Those studies do not test the review method I am recommending. Checking the service facts and raising unresolved promises is my practical judgement. The evidence reviewed here supplies no completion, conversion or support-volume estimate for that recommendation.

For the hypothetical application, I would take the claim that it was not received and the instruction to submit again back to the service owner. Receipt and safe resubmission still need answers before that wording can be approved.