Error States
What users see when things go wrong. These screens determine whether a user retries or leaves.
Failed to load data
An API call failed and the page can't render its primary content. This is the most common error state in any dashboard. Most teams show nothing or a browser error — both are wrong.
Failed to load data
Something went wrong on our end. This is usually temporary — try refreshing.
If this keeps happening, contact support.
Show whenever a primary data fetch fails (500, network error, timeout). Always offer a retry button. Never show a raw error message to the user unless they're a developer.
Permission denied (403)
The user tried to access a page or perform an action they don't have permission for. This happens constantly in multi-role admin tools. A generic 'Access Denied' page with no explanation is hostile.
You don't have access to this page
This section requires the Admin role. Ask your workspace owner to update your permissions.
Show when a user hits a 403 or tries an action their role doesn't allow. Always explain what permission is needed and who can grant it. Don't just say 'no'.
Network error / offline
The user lost their internet connection or the request couldn't reach the server. This is different from a server error — the problem is on the client side.
You appear to be offline
Check your internet connection and try again. Your unsaved changes are preserved locally.
Show when a fetch fails due to a network error (not a server response). Distinguish this from server errors so the user knows to check their connection, not wait for your team to fix something.
Rate limited (429)
The user or their integration hit a rate limit. This is common in API-heavy products and developer tools. Most apps show a cryptic error — you should explain what happened and when they can retry.
Too many requests
You've exceeded the rate limit. Please wait a moment before trying again. Your limit resets in 47 seconds.
Need higher limits? Upgrade your plan
Show when the API returns 429 Too Many Requests. Always tell the user when they can try again. If possible, show the reset time.
Resource not found (in-app 404)
The user followed a link to a specific resource (project, user, invoice) that no longer exists — maybe it was deleted, or the ID is wrong. This is different from a site-wide 404.
Project not found
The project you're looking for doesn't exist or may have been deleted. Check the URL or go back to your project list.
Show when a specific resource lookup returns 404. Be specific about what wasn't found. Don't use the generic site 404 page for this — it's confusing.
Form submission failed
The user filled out a form and hit submit, but the server rejected it. The form is still visible with their data, but they need to know what went wrong without losing their work.
Failed to save changes
The email address is already in use by another account. Please use a different email.
This email is already in use.
Show as an inline banner above or below the form when a submission fails. Never clear the form on error. Preserve all user input and highlight which fields need attention.
Action blocked by policy
The user tried to do something that's blocked by an org policy or plan restriction — not a permission issue, but a business rule. Examples: can't delete the last admin, can't exceed seat limit.
Action not allowed
Cannot remove the last admin
Every workspace must have at least one admin. Assign the admin role to another member first.
Show as a modal or inline message when a business rule prevents an action. Be specific about the rule and what the user can do instead.