Error messages let users know that a problem has occurred and what to do about it. Errors fall into two categories:Documentation Index
Fetch the complete documentation index at: https://mintlify.com/zendeskgarden/website/llms.txt
Use this file to discover all available pages before exploring further.
- System errors — the system failed to load or perform an action
- User errors — the user made an incorrect action or entered invalid input
| Component | Use for |
|---|---|
| Global Alert | System-level errors that interrupt the user’s entire session |
| Alert | Contextual errors related to a specific page or form |
| Notification | Errors from actions that could not be completed |
| Validation message | Inline field-level errors in forms |
Global Alerts
UseGlobalAlert to communicate system-level errors that interrupt a user’s task — such as losing connection to the service.
Anatomy
A Global Alert for errors should always include:- A title that announces what went wrong
- Content that describes how to address the issue (may include an anchor for more information)
- A button that provides a way to resolve the error, placed at the end of the alert
Layout
Global Alerts sit above all page chrome and push content down. They are the first element seen and announced by screen readers. For errors, Global Alerts should persist until the issue is resolved by the user or system — do not include a close button until the error is fixed.Alerts
UseAlert to communicate contextual errors on how to fix a problem. Alerts persist until they are dismissed by the user or the issue is resolved. They appear near the related content — most commonly at the top of a form when validation fails.
Anatomy
- Title — what went wrong
- Content — detail on how to fix it
- Close button — an icon button at the end of the alert
Usage with forms
When a form fails validation, place an Alert at the top of the form summarizing what went wrong, plus inline error messages on each individual field.Notifications
Use error notifications when an activity could not be completed — for example, a file upload that failed, or a background operation that encountered an error.Anatomy
- Title — what could not be completed
- Message — brief description
- Close button — icon button
Layout
Notifications appear in the top-right of the workspace and remain on screen for at least 5 seconds. Avoid covering important page elements.Form field errors
UseMessage with validation="error" to help users correct input errors as they happen. Clearly explain what went wrong and how to fix it.
Anatomy
- The input’s border turns red to indicate an error
- A detailed error message below the field describes what went wrong
Validate on submit
Trigger validation after the user submits, not on every keystroke.- Do
- Avoid
Show validation errors after the user has tried submitting the form. For severe cases (passwords, emails), validate on blur.
Preserve invalid data
When validation fails, keep the values the user entered in the fields. Clearing invalid data forces users to re-enter information and may cause the same mistake again.Error message content guidelines
Good error messages are:| Quality | Description | Example |
|---|---|---|
| Specific | Identify exactly what went wrong | ”Email address is missing the @ symbol” not “Invalid input” |
| Actionable | Tell the user what to do | ”Enter a valid email address, such as name@example.com” |
| Non-blaming | Do not blame the user | ”Email address is required” not “You forgot to enter your email” |
| Human | Write in plain language | ”Something went wrong. Try again.” not “Error code 500: Internal server error” |
Network error recovery
For network errors, give users a clear path to retry the action:Empty and 404 states
For empty states (no data) or not-found pages, distinguish between:- Empty: No data exists yet — give the user an action to create data
- 404 / Not found: The requested resource does not exist — give the user a way back
Accessibility
Error messages must be perceivable and understandable for all users. An accessible error message:- Is written in text — icons and color can supplement but never replace text
- Is close to the element that triggered the error
- Is informative — it helps the user resolve the issue
- References the field in code via
aria-describedby
role="alert" on inline error messages that appear dynamically after submission so screen readers announce them immediately.
For Global Alerts and page-level errors, screen readers will announce them automatically because they appear as the first element in the page flow.