Incident feed

The Incident feed is your real-time view of what's breaking. Rather than drowning you in individual errors, error.page groups related occurrences into incidents so you see signal, not noise.

Deduplication

Two errors are considered the same incident when they share a deduplication fingerprint — a hash computed from the error type, a normalised version of the message, and the endpoint. Normalisation strips out the parts that vary between occurrences (IDs, UUIDs, URLs, numbers, quoted strings), so these two:

Payment failed for order 88213 at /api/checkout/9f2a
Payment failed for order 90117 at /api/checkout/1b7c

collapse into one incident with an occurrence count of 2, instead of two separate rows.

What each incident shows

• Priority — a severity (low → critical) shown on every incident.
• Status — active, acknowledged, resolved, or regressed.
• Occurrences — how many times it has happened.
• Users affected — distinct end users, counted by an anonymous session hash (not the raw occurrence count).
• First and last seen — the window the incident has been active.
• AI classification — on paid plans, a severity + component label. See AI analysis.

A prioritized pipeline, not a firehose

The feed is ranked, not just chronological: open incidents first, then by severity, then by blast radius (affected users), then recency — so the worst, most-widely-felt issue is always at the top. Severity comes from the AI/heuristic classification and is escalated when an incident affects many users, so even Free-plan incidents are ranked.

Acknowledging

Click Acknowledge to mark an incident as being handled — useful when working as a team so two people don't chase the same bug. Acknowledgement is also emitted as a webhook event.

The status pipeline

• Acknowledge an incident to signal your team is on it. From then on, your branded page tells affected users "our team has acknowledged this issue and is working on a fix" — and it stays acknowledged even as new occurrences arrive, rather than flipping back to plain active.
• Regression — if an incident that was resolved starts happening again, it automatically reopens as regressed (a higher-severity state) and fires an incident.regressed webhook so the recurrence reaches your team, distinct from a routine new error.

Attachments (logs, files, screenshots)

Attach a screenshot, a log file, or a troubleshooting bundle to a report by posting multipart/form-data — they appear on the incident and are downloadable from the dashboard. This works from any client, not just the browser SDK, so a backend service, CLI, or desktop app can send them too:

curl https://error.page/api/v2/ingest \
  -H "X-Project-Key: YOUR_KEY" \
  -F error_type=server_error \
  -F message="Checkout failed" \
  -F attachments[]=@/var/log/app.log \
  -F image=@screenshot.png

Allowed types include logs and text (.log, .txt, .json, .csv, …), images, PDFs, archives and dumps (.zip, .gz, .dmp, …). Executable/scriptable files are refused.

Per-report limits by plan (total size of a report — text plus files):

Plan	Limit
Free	Text only, up to 3 KB
Pro	1 MB
Business	2 MB
Enterprise	Unlimited

Resolving an incident

There are three ways an incident reaches resolved — each records the time-to-recovery and notifies the users who opted in during the outage (see Engagement & lead capture):

• Manually — click Mark resolved on an incident. Available on every plan.
• Automatically (auto-resolve) — on the Business plan, incidents that go quiet (no new occurrences for a configured window) resolve themselves.
• On release — link the incident to a GitHub or Jira issue, and it resolves automatically when the fix is closed and shipped to production. See GitHub & Jira integrations.

Recovery notifications are sent from your custom sending domain when configured, otherwise from error.page. All three paths feed your recovery-rate metric on the dashboard.

Metrics

The dashboard summarises your feed:

• Errors today vs yesterday,
• Active incidents,
• Recovery rate — the share of the last 7 days' errors that reached a resolved state,
• Leads captured — email opt-ins collected during outages.

All of these are computed from your real data, scoped to your account.