Error Message Catalog Audit via Browser MCP

You are a senior product engineer cataloging every error message a user can encounter in a running web app via a browser automation MCP. You trigger errors intentionally — bad inputs, forced server failures via DevTools request interception, expired tokens via cookie deletion, rate limits via burst fire — and you capture each resulting UI. The output is a catalog: every error the user can hit, where it appears, what it says, whether it's recoverable, and what should change.

This is the negative-path companion to prompt 423 (which tests happy paths). Pair with prompt 435 (microcopy) for tone, prompt 430 (forms) for validation errors, and prompt 425 (synthesis) for sequencing.

Methodology: Trigger every error class, capture the resulting UI, judge against the "specific + actionable + recoverable" rule.

What good looks like: Every error message specifies what went wrong. Every recoverable error has a recovery path one click away. No "Something went wrong" anywhere. No raw stack traces, error codes, or backend jargon in user-facing copy. Errors render in a consistent location (toast for transient, inline for form, banner for blocking). Repeat errors don't pile up; idempotent retry doesn't multiply error toasts. Error states preserve user input. Sentry / Datadog captures the error with enough breadcrumbs for the team to debug, even when the user can't.

Error Class Inventory Checklist

For each app, identify and trigger every:

• Client validation errors — Field-level, form-level, before submit
• Server validation errors — Same shape as client where possible
• Permission errors — 401, 403, paywall, tier-restricted
• Not-found errors — 404, soft 404, expired link
• Conflict errors — 409, duplicate, concurrent edit (link to 434)
• Rate-limit errors — 429
• Server errors — 500, 502, 503, 504
• Network errors — Offline, slow timeout, DNS failure
• Auth errors — Expired session, revoked token, OAuth failure
• Third-party errors — Stripe declined, OpenAI rate limit, OAuth provider down
• Browser errors — JS exception, hydration mismatch (link to 431)
• Upload errors — File too large, wrong type, virus scan rejection (link to 422)
• Payment errors — Card declined, 3DS required, insufficient funds

Trigger Techniques (Browser MCP Tactics)

• Use page.route() to intercept and force specific status codes (500, 404, 429)
• Use page.setOffline(true) for network failures
• Manually delete the session cookie to trigger 401
• Submit obviously-invalid input to trigger validation
• Burst-fire to trigger rate limit
• Use Stripe test cards to trigger payment errors (4000 0000 0000 0002 = generic decline)
• Use expired test tokens to trigger auth errors

Per-Error Catalog Schema

For each error captured:

• Trigger — How you reproduced it
• Where — Route, action, component
• Surface — Toast / inline / banner / full-page / modal
• Message — The exact copy shown
• Recoverability — Auto-retry, manual retry button, navigate away, contact support, no recovery
• Input preservation — Did the user lose typed input?
• Logged — Does Sentry/Datadog capture it?
• Severity rating — User impact

Message Quality Checklist

For each captured message:

• Names what went wrong specifically
• States the fix when fixable
• Doesn't blame the user
• Doesn't apologize without adding value
• Has no error code as the only signal (codes OK as supplementary)
• Has no stack trace or technical jargon
• Translates third-party errors to product-language ("Card declined" not "Stripe error: card_declined")
• Is short enough for the surface (toast = one sentence, banner = up to two)

Recoverability Checklist

For each error:

• Retry button visible? One-click recovery?
• Form input preserved on validation / server-error?
• Session-expired error: clear path to re-login that preserves return URL?
• Payment error: clear path to update card?
• File upload error: clear path to choose another file (input not cleared)?
• Network error: queued for retry on reconnect OR explicit retry button?

Surface Consistency Checklist

For each error class, where does it appear?

• Field-level errors → inline, under the field
• Form-level errors → above or below the form, scrolled into view
• Page-level errors → banner or full-page
• Transient action errors → toast / snackbar
• Blocking errors → modal

Drift: same error class appearing in different surfaces across the app.

Duplicate / Spam Checklist

Many error UIs spam:

• Retry triggers a new error toast each time, stacking up
• Polling errors fire every interval
• Multi-step process errors fire at each step
• Hydration / boot errors flood the page

Verify de-duplication: same error within 5s shouldn't trigger 5 toasts.

Empty Catch Block Hunt

While auditing, watch for evidence of swallowed errors:

• Action that should have done something silently does nothing
• Form submit that silently fails (no toast, no inline error, but server didn't persist)
• Background sync that silently fails (UI shows the data but server doesn't have it)
• Save button that "works" but doesn't actually save

These are critical because the user has no signal something went wrong.

Sentry / Telemetry Correlation Checklist

For each error captured in the UI:

• Did Sentry receive it?
• Does the Sentry breadcrumb chain make the error debuggable?
• Are user-fixable errors filtered out (validation errors shouldn't page someone)?
• Are critical errors paging the right team / channel?

Error State Visual Treatment Checklist

• Icon + color signaling (red for danger, yellow for warning) — not color alone
• Sufficient contrast against background (link to 426)
• Doesn't obscure surrounding content unless intentional
• Aria-live region appropriate (alert for blocking, status for non-blocking)
• Mobile-friendly (long error messages don't overflow viewport)

Multi-Step Flow Error Behavior Checklist

For wizards / checkout / multi-step forms:

• Error in step 3 doesn't lose data from steps 1–2
• User can navigate back to fix the offending field
• Error state survives a browser refresh (or there's a clear restart path)

Privacy & Security in Error Messages Checklist

• Error messages don't reveal whether an email exists ("Email not found" vs "Invalid credentials")
• Error messages don't echo user input in dangerous places (XSS risk)
• Error messages don't expose internal IDs / paths / database errors
• Error messages don't reveal tenant data via cross-tenant probing (link to 427)

Loading vs Error State Disambiguation Checklist

• A long-running action that ends in error: clear transition from "loading" to "error"
• No state where loading and error are both visible
• No state where error is visible but spinner is still spinning

---

Calibration

Don't gate a launch on every error message being perfectly worded. Critical: any "Something went wrong," any error that drops user input, any silent failure. High: privacy leaks via error text, error spam from polling. Medium: tone inconsistency, missing retry buttons. Low: cosmetic icon improvements.

• Severity:

  • Critical — Silent failure (user loses work without knowing); error reveals sensitive info; user input lost on validation error
  • High — Generic error messages ("Something went wrong"); raw stack trace in UI; error spam from polling; no recovery from common errors
  • Medium — Inconsistent surface for same error class; missing retry button; tone drift across error messages
  • Low — Cosmetic improvements; slightly verbose copy

• Confidence ratings: Confirmed (triggered + captured), Likely (saw once), Speculative (suspect a class of error exists but couldn't trigger).

• Anti-hallucination guard: Don't claim an error is recoverable without clicking the recovery path. Don't claim Sentry captures it without checking Sentry. Don't claim input is preserved without typing input, triggering error, and verifying it's still there.

Output Format

Start with a 5–8 line executive summary: errors triggered, "Something went wrong" instances, silent failures found, top 3 fixes.

1. Trigger Matrix — Error classes covered, techniques used
2. Error Catalog — Full table: trigger × route × surface × message × recoverability × severity
3. Generic / Forbidden-Copy Findings — Every "Something went wrong" with location
4. Silent Failure Findings — Actions that failed without signaling
5. Recoverability Findings — Errors without a recovery path
6. Surface Drift Findings — Same error class in inconsistent locations
7. Privacy/Security Findings — Error messages leaking sensitive info
8. Telemetry Findings — Errors not captured or over-captured in Sentry

Close with a Prioritized Rewrite + Fix List: every Critical and High error with proposed new copy and the file or handler where the fix lands.