What is Error Message?
An error message is interface copy that tells a user what went wrong, what remains safe or unchanged, and what action can resolve the problem when possible.
What good error message looks like
Effective error messages identify the failed task in plain language, avoid blame, preserve important user input, and provide a specific recovery path instead of exposing technical jargon.
- State the problem from the user's point of view.
- Explain the next action when recovery is possible.
- Include technical detail only when the user can act on it or support staff need a reference.
A practical structure to follow
Use these elements as a decision checklist, not as a rigid formula. The exact wording should still fit the reader, context, and purpose.
- State the problem from the user's point of view.
- Explain the next action when recovery is possible.
- Include technical detail only when the user can act on it or support staff need a reference.
How to write error message step by step
- 1Identify the exact failed action.
- 2Determine whether user data was saved or lost.
- 3Translate the failure into plain language.
- 4Offer the most likely recovery step.
- 5Provide a support reference only if escalation may be needed.
8 Error Message examples
Read the examples for structure and choices rather than copying surface wording. Notice what stays consistent and what changes with audience or purpose.
We couldn't upload the file. It exceeds the 10 MB limit. Choose a smaller file and try again.
Your payment wasn't submitted. No charge was made. Check the card details or use another payment method.
That email address is already linked to an account. Sign in or reset your password.
We lost the connection before saving this change. Your previous version is still available.
The date range ends before it begins. Choose an end date after September 7.
We couldn't verify this address. Check the apartment number or continue with the address as entered.
Error Message templates
Replace every bracketed field with situation-specific information. A template is a starting structure, not finished copy.
We couldn't [action] because [specific cause]. [Recovery step].
[Task] wasn't completed. [Safety/status note]. [Next action].
[Field/problem] needs [specific requirement].
Common mistakes to avoid
- Displaying internal exception codes as the main message.
- Blaming the user with wording such as you entered this wrong.
- Saying something went wrong without a recovery action.
Final revision checklist
- Does the opening make the purpose clear quickly?
- Is every important claim, detail, or example doing a distinct job?
- Could a reader misunderstand any pronoun, transition, time reference, or instruction?
- Is the tone appropriate for the relationship and situation?
- Can you remove repetition without removing necessary context?
- If the writing contains factual claims, names, dates, quotations, or citations, have you verified them independently?
Questions about Error Message
What is Error Message?
An error message is interface copy that tells a user what went wrong, what remains safe or unchanged, and what action can resolve the problem when possible.
What makes Error Message effective?
Effective error messages identify the failed task in plain language, avoid blame, preserve important user input, and provide a specific recovery path instead of exposing technical jargon.
How do I write Error Message?
Start with the purpose and reader, then work through the structure in order. Draft for meaning first, check the examples for pattern, and do a final revision for clarity, accuracy, tone, and unnecessary repetition.
What should I avoid when writing Error Message?
Displaying internal exception codes as the main message. Blaming the user with wording such as you entered this wrong. Saying something went wrong without a recovery action.
How do I know whether a claim or source on a Error Message guide is stale, corrected, or still active?
Do not infer status from the page-wide update date. Check the controlling source or project record, the exact version/date last verified, and the trigger that could make the item changeable. Keep it active when the source still controls the exact claim; mark review due when a trigger has fired but the conclusion is not yet disproved; mark stale when the old version no longer controls; and use corrected, retracted, withdrawn, or superseded when the editorial history requires it. The correction level should match reader impact: cosmetic edits are not the same as a material factual correction or a critical source failure.
If a source behind Error Message changes, how do I know which other claims or guides need review?
Use the dependency map rather than reviewing the entire site blindly. Identify the exact claim or example that depends on the source, classify the dependency as direct, shared, advisory, or independent, and record why the source changed. Direct dependents should be reviewed immediately when a controlling source is corrected, retracted, superseded, or no longer supports the claim. Shared dependents can be queued by source/claim ID and scope. Replace the source only when the replacement performs the same evidentiary job—or change the claim. Keep the old source/status in the ledger, then propagate the review to templates, examples, and related guides only where that dependency actually exists.
How can editors track a source change for Error Message without reviewing the entire site?
Use persistent claim, source, and dependency records. Link only the claims that truly depend on a source, then change that source record’s status in the Writing Authority admin when it is corrected, superseded, stale, withdrawn, or retracted. The registry queues the linked claims with a reason code and priority. Reviewers can see the affected guide, inspect the source/dependency IDs, revise or replace the evidence where necessary, and close the queue item after verification. Original site-created examples and templates remain independent unless they contain a real external factual dependency.