Error Messages and Microcopy for SaaS
Error messages appear at the worst moments: when something has gone wrong and the user is already annoyed. Clear, specific microcopy turns those moments into a quick fix instead of a support ticket.
How should SaaS error messages be written?
A good error message says what happened, why if it helps, and exactly what to do next, in plain words, next to where the problem is. It doesn’t blame the user, doesn’t show codes without explanation, and keeps the user’s input so they can fix it. WCAG 3.3.1 requires detected input errors to be identified and described in text (W3C on error identification).
What do weak and strong error messages look like?
The pairs below show common SaaS errors before and after. Notice that the fixed versions are not longer for the sake of it; each adds the one piece of information the user needs.
| Situation | Before | After |
|---|---|---|
| Wrong date format | Invalid input | Enter the date as DD/MM/YYYY, for example 07/10/2026 |
| File too large | Upload failed (413) | This file is 32 MB. Upload files up to 25 MB, or compress it first |
| Session expired | Unauthorized | You were logged out after 12 hours. Log in again; your draft is saved |
| Payment declined | Error processing payment | Your bank declined the card. Try another card or contact your bank |
| No permission | Access denied | Only admins can change billing. Ask Dana Kim, your admin |
Even better, accept ‘7 Oct’ and convert it. The best error message is often a validation rule that is less strict.
How should toasts and confirmations work?
Use toasts for quick confirmations and recoverable errors, with an action such as Undo or Retry, and keep them on screen long enough to read. Use confirmation dialogs only for actions that can’t be undone, and name the action on the button.
A dialog that says ‘Are you sure?’ with OK and Cancel trains users to click OK without reading. Name the action and the consequence instead.
What tone should SaaS microcopy use?
Use plain, calm, specific language. Write as a helpful colleague would: no jokes during errors, no blame, no jargon. Keep button labels as verbs that describe the result, such as ‘Save invoice’ or ‘Send 2 invites’, not ‘OK’ or ‘Submit’. Empty screens need the same care; see empty states. Form-specific errors are covered on signup form design and login page UX.
Every error should end with a next step.
If the user can’t tell what to do after reading an error, it isn’t finished.
What should a 404 or error page include?
A 404 or error page should say what happened in one line, offer search and links to the most used pages, and give a way to report the problem. In an app, keep the navigation visible so users aren’t stranded. All of these are checked in the UX audit checklist, and accessibility requirements for errors on SaaS accessibility.
Frequently asked questions
How do you write a good error message?
Say what happened, why if it helps, and exactly what to do next, in plain words, next to the problem.
What does WCAG require for error messages?
Success criterion 3.3.1 requires detected input errors to be identified and described in text.
When should a SaaS app use a confirmation dialog?
Only for actions that can’t be undone. Use Undo for everything else.
What should a toast notification include?
A short message and, where useful, an action such as Undo or Retry.
What tone should error messages use?
Plain, calm and specific, without blame, jokes or jargon.
What should button labels say?
The result of the action, such as ‘Save invoice’, not ‘OK’ or ‘Submit’.
Sources & further reading
Standards and platform rules change. These sources let you verify the current requirements directly. All screens shown are mock-ups of fictional products.