Prompt Library coding beginner

ChatGPT Prompts for Error Messages: UX-Friendly, Actionable Errors

ChatGPT prompts for writing user-facing error messages, developer error codes, and validation messages that help users recover fast.

Tested on: GPT-4oClaude 4Gemini 2.5

The Prompt

Act as a UX writer and software engineer who has designed error handling systems for consumer apps with 1M+ users.
Write error messages for:
Application type: {web app / mobile app / API / CLI tool}
Error scenario: {describe what happened — what the user tried to do and what went wrong}
User type: {end consumer / developer / internal admin}
Brand voice: {professional / friendly / technical / casual}
Platform: {provide any existing error message patterns for consistency}

For each error scenario, provide:
1. User-facing message (what the user sees):
   - Error title (under 6 words)
   - Error explanation (1-2 sentences: what happened + why — no technical jargon)
   - Recovery action (what to do next — specific and actionable)
2. Developer/log message (what gets logged — includes error code, stack context, affected resource)
3. Error code naming (format: CATEGORY_SPECIFIC_ERROR, e.g. AUTH_TOKEN_EXPIRED)
4. HTTP status code (if applicable)
5. Retry guidance (should they retry? How long to wait? When should they contact support?)

Error quality checklist (apply to each message):
- Does it say what happened? (not just "something went wrong")
- Does it say what to do next?
- Is the tone appropriate for the severity?
- Does it avoid blame ("you entered an invalid...")
- Is technical jargon absent from user-facing copy?

Constraints:
- Never use "unexpected error" — be specific about what was unexpected
- Recovery action must be specific — not "please try again later"
- Log messages must never contain PII (user emails, passwords, tokens)
- User messages must not expose internal implementation details (stack traces, table names)

Variables to fill in

  • {error scenario} What the user tried to do and what went wrong
  • {user type} End consumer, developer, or internal admin — affects tone and technical depth
  • {application type} Web app, mobile app, API, or CLI tool
  • {brand voice} The tone appropriate for your product

How to use this prompt

  1. Run this for every error state in your application — not just the common paths
  2. Use the error code naming convention to build a consistent error catalog
  3. Apply the quality checklist to audit your existing error messages
  4. Log the developer message format to your observability tool for consistent searchability
Mobile app error message displayed on phone screen with clear action button
Photo by Jamie Street on Unsplash

‘Something went wrong’ is not an error message

Vague error messages force users to call support, check documentation, or give up. An error message that says exactly what failed and what to do next resolves the majority of issues without any human intervention. The prompt’s quality checklist includes ‘does it say what happened?’ specifically because this is the most common failure in error UX.

Blame language converts errors into churn

Error messages that say ‘You entered an invalid email address’ feel accusatory even when technically accurate. ‘That email address doesn’t match our records — try a different one or create an account’ says the same thing but puts the user in a problem-solving mindset instead of a defensive one. The prompt explicitly prohibits blame language.

Log messages must never contain PII

Logging user emails, passwords, or authentication tokens in error messages is both a security risk and a compliance violation under GDPR and CCPA. A log that contains Failed auth for [email protected] is a data breach waiting to happen. The prompt’s PII constraint prevents this from appearing in AI-generated log formats.