Error State Microcopy: Headlines, CTAs & Tone Patterns | Northbase
Permission & Access Control Patterns Error States Microcopy Analysis Microcopy Analysis Quantified headline, body text, tone, and recovery patterns across 83 error states.
Have questions about Error States? Get instant answers from our AI assistant. Trained on our research data from leading enterprise systems.
Table of Contents
Headline Patterns Body Text Patterns Tone Analysis
Introduction
Error state microcopy serves a different purpose than empty states—it must explain what went wrong, reassure users, and guide recovery. Across 83 error instances, we found dramatic variation in tone: technical systems favor terse technical language while collaboration tools use apologetic, conversational copy.
This chapter quantifies what 10 enterprise systems actually write in their error states, revealing patterns in headline structure, body text length, tone distribution, and recovery copy.
Headlines 83 47% have no headline (inline errors) Body text 83 Average 9 words when present Tone 83 35% neutral, 18% technical, 15% apologetic Recovery copy 39 "Retry" most common verb (23%) Contractions 83 72% of systems use contractions
Headline Patterns
Presence Distribution Has Headline Count % Primary Contexts No headline 39 47% Inline validation, body-only errors With headline 44 53% Modals, full page, toasts
Nearly half of error states have no headline at all—inline validation relies entirely on body text. Headlines appear primarily in interrupting patterns (modals, full page, toasts).
Length Distribution Words Count % Examples 1 4 9% "Error", "404" 2 8 18% "File unsupported", "No connection" 3 10 23% "Issue not found", "Something went wrong" 4 9 20% "File exceeds size limit", "Can't import CSV file" 5 6 14% "This page couldn't be found" 6+ 7 16% "We can't find the page you're looking for"
Most common: 2-4 words (61% of headlines). Error headlines are shorter than empty state headlines—urgency demands brevity.
Structure Patterns "[Action] failed" — 18% of headlines
The dominant pattern for system/technical errors.
The '[Action] failed' pattern: clear, direct, no blame on user
"File failed to upload"
"Failed to load sessions"
"Import failed"
Used by: Linear (4), Figma (1), Retool (2)
"Can't/Couldn't [action]" — 16% of headlines
Ownership language—the system takes responsibility.
Atlassian's 'Couldn't' pattern takes ownership: 'We're having some trouble...'
"Couldn't create the work item"
"Can't import CSV file"
"We couldn't load your dashboard access settings"
Used by: Atlassian (3), Airtable (2), Asana (1), Notion (1)
Single word "Error" — 9% of headlines
Minimal approach for technical systems.
GitHub's minimal approach: 'Error' headline, specific details in body
"Error" (GitHub uses twice)
"Error." (Stripe—note the period)
"404"
Used by: GitHub (2), Stripe (1)
"[Noun] + [state]" — 14% of headlines
Descriptive, status-focused.
"File unsupported"
"No connection"
"Preview Unavailable"
"Title required"
Used by: Slack (2), Linear (2), Notion (1)
Conversational openers — 7% of headlines
Informal, personality-driven.
Figma's conversational 404: 'Hmm' softens the error, 'we' shares responsibility
"Hmm, we couldn't find that one" (Figma)
"Oops!" (Retool)
"Looks like network is down!" (GitHub)
Used by: Figma (1), Retool (1), GitHub (1)
Headlines by System System Avg Length Dominant Pattern Notable GitHub 1 word Single word "Error" Most minimal Linear 3 words "[Action] failed" Consistent structure Airtable 5 words "Can't [action]" Uses contractions Atlassian 6 words "We couldn't [action]" Longest headlines Figma 4 words Conversational Uses "Hmm" Retool 3 words Title Case "File Size Limit Exceeded"
Body Text Patterns
Length Distribution Words Count % Use Case 0 (none) 8 10% Terse inline, headline sufficient 2-5 19 23% Simple validation, brief errors 6-10 24 29% Standard explanation 11-15 16 19% Detailed explanation 16-20 9 11% Complex errors, recovery guidance 21+ 7 8% Full page errors, multiple recovery paths
When present, 6-10 words is most common (29%). Error body text is slightly shorter than empty state body text—users are already frustrated.
Purpose Categories Explain what happened (38%): What went wrong.
"Your card was declined."
"File exceeds maximum allowed size"
"The requested data was not available locally"
Explain why (24%): Root cause or reason.
"Your request was in live mode, but used a known test card."
"They may not have access to teams in your organization."
"For security reasons, we cannot share information..."
Guide recovery (22%): What to do next.
"Try uploading a .zip version of this file instead."
"Refresh the page and try again."
"Check your spelling in the address bar."
Reassure (10%): Acknowledge state, reduce anxiety.
"Sit tight while we reconnect you."
"You'll be able to send messages as soon as you're back online."
Instruct (6%): Tell user what's required.
"Please upload a CSV file that is no larger than 10 megabytes."
"Name must be at least 4 characters long"
Reassurance in action: 'Sit tight' acknowledges the problem while showing active recovery
Specificity Patterns
File sizes: "5 MB", "10 MB", "100 MB each"
Dimensions: "128x128px or less (was 4474x4167px)"
Product IDs: "prod_TcvVpIlW2dy7Qm"
File names: "Cursor.app", "Affinity.dmg", "file-01.csv"
Error IDs: "Error ID: b672ec8c2a924e918d736e38ae6a8004"
JSON positions: "position 2 (line 1 column 3)"
Stripe's developer-friendly specificity: exact product ID for debugging Technical systems (Stripe, Retool, Linear) show technical details. Consumer-facing tools (Slack, Asana) keep details minimal.
Body Text by System System Include Rate Avg Length Style Atlassian 100% 15 words Detailed, multiple sentences Asana 100% 14 words Conversational, specific Slack 90% 10 words Reassuring, helpful Stripe 88% 8 words Technical, specific Retool 88% 10 words Technical, error IDs Linear 78% 10 words Clear, actionable Figma 70% 8 words Brief, technical Notion 67% 10 words Instructional GitHub 63% 8 words Casual, minimal Airtable 56% 7 words Terse
Tone Analysis
Overall Distribution Tone Count % Example Neutral 29 35% "Unable to load this view" Technical 15 18% "Network request failed" Apologetic 12 15% "Sorry, something went wrong" Instructional 10 12% "Please provide a valid email" Terse 8 10% "Invalid email" Explanatory 5 6% "They may not have access..." Conversational 4 4% "Looks like you need access"
Tone by Error Type Error Type Primary Tone Secondary Avoid Form validation Terse (40%) Instructional (30%) Apologetic File errors Instructional (35%) Neutral (30%) Technical Network errors Reassuring (40%) Neutral (30%) Terse 404 pages Conversational (40%) Explanatory (30%) Technical Permission denied Explanatory (50%) Collaborative (30%) Terse System errors Technical (45%) Neutral (35%) Conversational
Permission errors deserve collaborative tone: 'Looks like' softens denial, request button enables recovery
Tone by System System Primary Secondary Notable Pattern Atlassian Apologetic (50%) Explanatory (25%) "We couldn't", "We're having trouble" Asana Conversational (38%) Instructional (25%) "Looks like", collaborative Slack Reassuring (30%) Apologetic (20%) "Sit tight", "Sorry" Figma Technical (40%) Conversational (20%) "An error occurred while..." + "Hmm" Stripe Technical (38%) Neutral (25%) Developer-focused details Linear Neutral (33%) Technical (22%) Consistent, minimal Retool Technical (50%) Neutral (25%) Error IDs, JSON positions GitHub Terse (38%) Casual (25%) Single word headlines, Star Wars Notion Neutral (67%) Instructional (17%) Minimal, functional Airtable Terse (33%) Neutral (22%) Shortest copy overall
Product type predicts tone. Technical systems favor technical/neutral. Collaboration tools favor apologetic/conversational.
Apologetic Language Patterns "Sorry" usage (8 instances):
Slack: "Sorry, Cursor.app is a type of file not supported..."
Stripe: "Sorry, something went wrong."
Notion: "Sorry, this file type is not supported."
"We" ownership (12 instances):
Atlassian: "We couldn't", "We can't", "We're having trouble"
Figma: "we couldn't find that one"
Linear: "We could not find the page"
"Couldn't" without "we" (6 instances):
Asana: "Couldn't Upload File(s)"
Airtable: "Couldn't upload. Try adding again."
Notion: "This image couldn't be loaded."
Unlock 6 more sections
Subscribe to access the full content and unlock all chapters.
Locked sections:
Write error messages that users actually understand (5 headline structures) Know exactly how much explanation to give (body length data by error type) Match your product's personality (tone analysis across 10 systems) When to say 'we' vs 'you' vs stay neutral (with usage data) Design recovery copy that drives clicks (button vs link patterns) Contraction usage rules: When casual works vs when to stay formal See plans → 
