Separate network, permission, and server failures

What it is

A whole view that failed all looks like “won’t open,” but the cause splits three ways, and so do the actions a person can take. A network problem sits on the path from this device to the server; another network or a later retry may suffice. A permission problem sits on this identity; retry will not help—switch account or request access. A server problem sits in the product; waiting or reporting is nearly all that is left. One shared “something went wrong” sends people with no network to an admin, and people with no permission into refresh loops. Classification is for picking the next step, not for reading status codes aloud.

Why it happens

People choose a strategy from a cause: check the cable, change account, give up. The closer the page’s cause is to an executable strategy, the shorter the error page. Drawing three failures as the same sad illustration collapses strategy into “tap again,” which helps only one of the three. Classification also sets tone: network can be “on your side,” permission “this account,” server “on ours.” The wrong tone becomes blame—the device is offline and the copy says the server is busy. Status codes are unusable for most people; the strategy sentence is usable. A degraded page is a soft form of server failure: some capability remains, so say which part is gone rather than playing dead on the whole view.

Where it stops holding

The client sometimes cannot tell a timeout from a dead server. Rather than guess wrong, offer both “check the connection” and “view the status page,” and do not pin a confident charge. Insufficient permission and missing object are often the same backend response to avoid leakage; the error page should not pretend “this project exists but you cannot see it” or “it definitely does not exist.” Mixed failures (expired login plus a dead network) should handle the locally knowable layer first (no network), then identity. On internal tools a status code may appear as secondary information; it still does not replace the strategy sentence.

Applying it

• Ship three error-page templates—network, permission, server—with primaries of retry / request-or-switch-account / status-or-back.
• Write strategy, not a status code as the title; put the code in a secondary place when debugging needs it.
• When offline can be known locally, do not wait for a server timeout to show a “server error.”
• Verify by going offline, using an unauthorized account, and simulating a server 500: the next step on the three pages should differ. The same next step means classification never happened.

Related

• Within the group: E6.10.1 An error page must offer a way back and a way to retry · E6.10.3 An error page must not throw away what the user already typed
• Adjacent: E6.14 Offline and connectivity notices · E6.06 Empty states · E5.18 Permission visibility of navigation
• Search terms: error diagnosis · offline vs forbidden · server error page