Error Messages That Help, Not Blame
Practical templates for the most common app error types, written with empathy and a clear next action for the user.
Most apps get error messages wrong in the same direction. They write them last, under deadline, by whoever is nearest the keyboard. The result is blame-heavy, vague, or outright cryptic copy that leaves users stuck and quietly annoyed.
This post gives you templates for the errors that appear most often in mobile and web apps. Each template follows the same structure: name what happened, say why (briefly and in plain language), give one next action. Use them as starting points, then adjust for your product's tone.
Why Error Messages Matter More Than You Think
An error is already a bad moment for your user. They wanted something, and they did not get it. The error message is your product speaking to them during that bad moment. What it says, and how it says it, shapes whether they try again or close the app.
Vague messages like "An error occurred" tell users nothing. They do not know if the problem is on their end or yours. They do not know whether to retry, refresh, check a setting, or just give up. The message has failed before they have even finished reading it.
Blame language is worse. "Invalid input" tells the user they did something wrong without telling them what or how to fix it. "You must complete all required fields" sounds like a scolding. Neither message helps.
The goal is not to be cute or to over-apologize. The goal is to be useful. A useful error message does three things quickly: it names what happened, it gives the briefest honest reason, and it points to one action.
The structure to follow
What happened. Why it happened (one short clause). What to do next.
Keep the "why" to a single clause unless the reason is genuinely complex. Keep the "what to do" to one step. Giving users a list of possible fixes adds friction when they are already frustrated.
Templates by Error Type
1. Network or connectivity errors
These happen when the user's device loses its connection or your server is unreachable. Users often do not know which one caused the problem, so do not pretend you do either.
Template:
"Could not connect. Check your internet connection and try again."
Variation when you know it is your server:
"Our servers are not responding right now. Try again in a few minutes."
What to avoid: "Network error 503." Codes mean nothing to most users. If you need the code for support tickets, put it in small text below the message, not in the headline.
2. Form validation errors
Validation errors get written in the most punishing language of any error type. They are also the most common. Every signup form, checkout flow, and settings screen has them.
Template (field-level):
"Email address is missing. Add your email to continue."
Template (password rules):
"Password is too short. Use at least eight characters."
What to avoid: "Invalid email." Invalid means broken or wrong. It puts the fault on the user without helping them understand what the right version looks like. Describe the rule, not the failure.
A practical note: validate on blur, not on submit. Showing errors as the user moves between fields is less confrontational than revealing every problem at once after they press a button.
3. Empty states that feel like errors
An empty state is not technically an error, but users often experience it as one. They land on a screen and see nothing. If you do not explain the emptiness, they assume something broke.
Template:
"No transactions yet. Make your first purchase to see it here."
Template (search with no results):
"No results for '[search term]'. Try a shorter or different word."
The key move here is to explain why the screen is empty and give one action that fills it. Do not just show a blank screen with an icon.
4. Permission errors
These happen when a user tries to do something they are not allowed to do, either because of their account tier, their role in a team, or an operating system permission you need.
Template (account tier):
"This feature is on the Pro plan. Upgrade your plan to use it."
Template (OS permission, like camera access):
"Camera access is off. Go to Settings and allow access to take photos."
What to avoid: "You don't have permission to do that." That sentence tells the user they are blocked without helping them get unblocked. Always name the specific thing blocking them and the specific step to fix it.
5. File or upload errors
Upload flows fail in several distinct ways: file too large, wrong format, corrupted file, or a failed transfer midway through. Each one needs a different message.
Template (file size):
"This file is too large. Upload a file smaller than [X]."
Template (wrong format):
"That file type is not supported. Upload a JPG, PNG, or PDF."
Template (failed transfer):
"Upload did not complete. Check your connection and try again."
Notice that each one names the specific constraint. "File upload failed" on its own sends the user back to square one with no information.
6. Session and authentication errors
Sessions expire. Tokens go stale. Users get logged out without warning. How you handle this moment is a trust signal.
Template (session expired):
"Your session has ended. Sign in again to continue."
Template (wrong credentials):
"Email or password is incorrect. Try again or reset your password."
A note on security: do not confirm which field is wrong. Saying "Password incorrect" tells an attacker the email is valid. The joint message above is the standard approach.
7. Destructive action confirmations
Strictly speaking, these are not error messages. But they exist to prevent errors, so they belong in this list. Deletion, cancellation, and irreversible actions all need a confirmation that names the consequence.
Template:
"Delete this project? This removes all files and cannot be undone."
What to avoid: "Are you sure?" It adds a step without adding information. Name what will be deleted and whether it can be recovered.
The Tone Problem
Templates give you structure. Tone is harder.
A common mistake is to over-apologize. "We're so sorry something went wrong! Our team is working hard to fix this issue as soon as possible!" reads as anxious. It adds length and says nothing specific. One short acknowledgment is enough if the problem is genuinely on your end.
Another common mistake is false cheerfulness. "Oops! Looks like something went sideways!" can feel dismissive when a user just lost data or a failed payment is blocking their order.
Match the severity of the error to the weight of your language. A form validation error does not need an apology. A data loss situation does. A payment failure needs clarity, not warmth.
Consistency matters more than wit. If you are building a serious productivity tool, playful error copy reads as mismatched. If you are building a casual consumer app, clinical language feels cold. Pick a register and stay in it across all your error states.
Building Error Messages Before You Need Them
Most teams write error messages reactively, when a bug is filed or a user complains. That produces inconsistency because different people write different messages in different moods.
A better approach is to inventory your error types before you start building screens. List the actions users can take in your app. For each action, ask what can go wrong. Map each failure mode to one of the categories above. Write the message before the code.
This is especially useful when working with generated code. When a model or agent builds your screens, it tends to use placeholder error strings like "Error" or "Something went wrong." Reviewing and replacing those strings is fast if you have a template to pull from and slow if you have to write from scratch every time.
Your users will see these messages. Treating them as an afterthought means your product speaks its worst copy at its worst moments.
A Quick Checklist
Before you ship any screen with an error state, run through these four questions:
- Does the message name what happened in plain language?
- Does it avoid blaming the user?
- Does it give exactly one next action?
- Is the tone consistent with the rest of the product?
If all four are yes, ship it. If any are no, revise the copy before the error state goes live. The fix usually takes five minutes. The trust it protects takes much longer to rebuild.
Error messages are a small surface, but they appear at the worst moments in a user's session. Designing them with the same care as your primary flows is one of the fastest ways to improve how your product feels without changing a single feature. Start with the templates above, adapt them to your voice, and get them into your design system before you need them.
Subscribe to The Signal
The top 5 scored app ideas, delivered fresh.