Should error messages apologize? (2013)

Original Article ↗ Hacker News Discussion ↗

Whether software should say “sorry” in error messages divides opinion between those who prefer human, empathetic wording and those who want terse, machine-like precision. Many argue that apologies, jokes, and cutesy language feel insincere or patronizing, especially when they obscure actionable details like what went wrong, what to do next, or an error code to search. Others note that tone and indirectness can be culturally dependent, but there is broad agreement that clarity, brevity, and guidance toward a fix matter far more than politeness.

Whether error messages should apologize

  • Many argue “sorry” is usually unnecessary bloat. It rarely helps users recover and often feels insincere or fake, since software and engineers aren’t actually present or emotional at the moment of failure.
  • Some think apologies are appropriate only for serious or unrecoverable problems (e.g., data loss, prolonged outage) or when the organization has clearly failed and is working to fix it.
  • Others see a polite apology as part of good customer service: if the user is blocked, the product has failed them, even if they “misused” it.

Tone: humanized vs machine-like

  • Strong dislike for cutesy, infantilizing, or overly cheerful messages (“oopsie”, mascots, smiley/frowny faces). Seen as patronizing, unprofessional, and especially grating when users are stressed.
  • A sizable group prefers terse, impersonal, “machine-like” errors (Unix-style) that avoid anthropomorphism and fake empathy.
  • Some like a light human tone (“we’re sorry, your email failed to send”) to avoid sounding like the software is yelling, as long as it’s brief and respectful.

Clarity, actionability, and detail

  • Broad agreement that the core requirements are:
    • Be concise and specific about what went wrong.
    • Avoid or explain jargon for end users.
    • Indicate what the user can do next (retry, wait, change input, contact someone, follow a link).
    • Provide identifiers or codes that can be searched or given to support.
  • Vague “Something went wrong. Sorry.” messages are heavily criticized; they block users and hide useful diagnostics.

Audience, responsibility, and agency

  • Distinction between:
    • User-facing messages (polite, high-level, action-focused).
    • Developer/administrator messages (more technical, may include stack traces, config paths, etc.).
  • One long subthread debates “who is speaking”: the user’s tool, the vendor, or an administrator. In free/open-source contexts, apologizing can imply a control relationship some consider undesirable; in proprietary/vendor-controlled software, an apology on behalf of the company is seen as more appropriate.

Culture and language

  • Some English dialects use “sorry” to express sympathy, not guilt; others hear it as admitting fault, which affects how error apologies are perceived.
  • Several non‑US speakers note that localized UIs often drop “please/sorry” entirely as unnecessary or culturally mismatched.

Humor and insults

  • Mild humor or easter eggs can be appreciated in low-stakes cases.
  • Excessive cuteness or joking in serious failures is widely disliked.
  • A few enjoy deliberately snarky or aggressive errors in niche or game contexts, but recognize it’s inappropriate for general software.