Bugsnag

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me error monitoring that replaces Bugsnag — and know what makes it ALMOST.

The ingest and the dashboard are a weekend. **Grouping is not.** Keeping one issue together when the stack trace shifts, a function is renamed or a line moves is subtler than hashing a message, and getting it wrong gives you either one issue containing everything or ten thousand containing one event each. Both are unusable. That, plus a stability score that means something, is where the work is.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker for ingestion, so a flood never slows the endpoint
- Caddy in front

THE DATA MODEL
- projects, releases: id, project_id, version, deployed_at, commit_sha, session_count
- issues: id, project_id, fingerprint, title, culprit, severity, status, first_seen_release, last_seen_release, first_seen_at, last_seen_at, event_count, user_count, snooze_until
- events: id, issue_id, event_id, at, release, environment, severity, message, exception_json, stacktrace_json, breadcrumbs_json, request_json, tags_json, user_hash, sdk
- sessions: id, project_id, release, started_at, had_error, user_hash — this table is what makes a stability score possible, and it cannot be reconstructed later
- artifacts: source maps per release

GROUPING, WHICH IS THE PRODUCT
- Fingerprint from the exception type plus the stack frames that belong to your own code, ignoring library and framework frames. That single rule is what makes the same bug from twenty call sites one issue
- Normalise the variable parts out of the message before hashing: numbers, identifiers, addresses, paths, hex strings
- Ignore line numbers within a frame where the function name is stable, so a refactor that moves code does not split an issue
- Respect an explicit fingerprint from the SDK when one is set
- Merge and split by hand, both recorded
- Test it against a few thousand real errors and tune until the issue list is something you would read every morning. That tuning is the job

RELEASE HEALTH
- Every session recorded — started, and whether it had an error. Stability is sessions without an error over total sessions, per release
- A release whose stability drops below the previous one is the alert that matters, and it is far more actionable than a raw error count, which moves with traffic
- First and last seen release per issue, so a regression is identifiable
- A regression reopens the issue and names the release it returned in

SOURCE MAPS
- Uploaded per release from CI with a token, applied at read time so a map uploaded later still fixes older events
- A clear message when a map is missing or does not match, because a minified trace is no trace at all

THE REST
- Breadcrumbs, the request with authorisation and cookies redacted, tags for release, environment and anything the SDK adds
- A user identifier hashed with a salt, so 'how many people hit this' is answerable without storing who
- Rate limits per project with a burst allowance and a clear response when shedding — an error tracker that falls over during an incident is useless exactly when needed
- Alerts on a new issue, a regression, a rate threshold, or a stability drop, throttled per rule so one bad deploy sends one alert
- Event retention with a sweeper; issue-level counts survive expiry

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT, SMTP_URL
- Migrations on boot, each once; nightly backup — events are expendable, issues are not
- Health endpoint reporting ingest lag and queue depth

WHAT MATTERS MOST
Grouping and sessions. Build the fingerprint against real data and record sessions from the first day, because the stability score is the number worth having and it cannot be backfilled.