Branded error pages

When your site errors, error.page shows your users a page you designed instead of a stack trace or a blank screen. You control the copy, the colours and the template from the Branded Pages editor.

Templates

Pick the layout that fits the moment:

• Calm — a reassuring message with a gentle spinner and a single call to action. Best for most sites.
• Progress — a live "we're working on it" bar that fills as we retry and completes the moment you recover.
• Detailed — help links, a reload shortcut, and (on Pro) "notify me when it's fixed" email capture.
• Minimal — ultra-clean: just your message and an accent line, no spinner or chrome.
• Playful — a friendly animated emoji and warm, rounded styling to soften the moment.
• Status — status-page style, with an "Investigating" pill and a live progress bar.

The live preview in the editor updates as you pick, so you can see each one before you deploy.

Show a hint of the error

Toggle "Show a 'What happened?' dropdown" to add an expandable line that reveals a plain-language hint about the type of error (e.g. "Connectivity issue" or "Server error") with a short reference code. It's handy for technical audiences who want a little more than "we're on it."

It's safe by design: the hint is derived only from the error classification — it never exposes the raw error message, stack trace, or any technical detail from your app.

Copy

Every page has:

• a header — the headline your users read first (e.g. "We're working on it"),
• a body — a sentence or two of reassurance,
• a call to action — button text and where it links (your homepage, status page, or support).

Leave a field blank and error.page falls back to sensible, friendly defaults tuned to the type of error (network, server, JavaScript crash, and so on).

Colours

Set your primary, background and text colours to match your brand. The live preview on the dashboard updates as you type, so what you see is what your users get.

Where the page shows

• Inline overlay — the SDK renders your page as an overlay on the failing page, so the user never leaves.
• Standalone URL — every project has a public page at https://error.page/error-page/your-slug you can link to or use as a fallback.
• Your own domain — on paid plans, serve it from errors.yourcompany.com. See Custom domains.

Tips

• Keep the header short and human. Users are already frustrated — acknowledge it.
• Point the call to action somewhere useful: a status page, your Twitter/X, or a support inbox.
• On paid plans, add an email capture so an outage becomes an opt-in.