Pattern 18 · Trust & safety

Error & refusal states

Generic "Something went wrong" and preachy refusals leave users with a dead end and lost work.

By Aleksey StepikinUpdated October 20263 min readLive demo
Live demo · try it

An interactive mock built in plain HTML, CSS and JavaScript. Data is fictional; no model is called.

FitWhen to use it — and when not

Use it when

  • Every AI surface — failures are normal, not edge cases
  • Policy-limited domains (health, finance, legal, content)
  • Large inputs that can exceed limits

Skip it when

  • There is no "when not" — design these states before launch

AnatomyThe parts of the pattern

  1. What happenedOne plain sentence, no codes.
  2. What is safe"Your prompt is saved", "Nothing was sent".
  3. Way forwardRetry, alternative task, or smaller input.
  4. Partial resultKeep whatever was already generated.

GuidelinesDo & don’t

Do

  • Preserve the prompt and partial output on failure.
  • Offer a useful alternative with every refusal.
  • Separate "we failed" from "we will not" from "too big".

Don’t

  • Lecture the user in a refusal.
  • Show raw provider errors or HTTP codes.
  • Clear the input box on error.

In the wildReal-world examples

ChatGPTClaudeGeminiPerplexity

Products named for reference only — no affiliation, and the demo above is an original illustration, not a copy of their UI.

For engineersImplementation notes

  • Map provider errors (429, 5xx, context length, safety) to a small set of typed UI states.
  • Retry transient errors automatically with backoff before showing anything; show the state only when it persists.
  • Persist drafts locally so a reload never loses a long prompt.

Trust & safetyRelated patterns

All 26 LLM UX patterns

Building an AI product?

I design and ship AI products end to end — LLM interfaces, agents, RAG, billing — from concept to a live product in weeks, not quarters. Tell me what you are building and get a fixed estimate.

Get an estimateBook a call

Create bold.
Deliver better.

See our workGet in touch