Raygun

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 the crash reporting and real user monitoring that replaces Raygun.

The combination is the idea: **an error and a slow page are the same event seen twice**, and having both from the same visitor is what makes either useful.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A tiny script on the page — no library, no framework
- Caddy in front

THE DATA MODEL
- groups: id, fingerprint, title, culprit, first_seen, last_seen, count, status, resolved_in_release
- occurrences: id, group_id, release, environment, message, stack_json, context_json, session_id, at
- sessions: id, visitor_hash, started_at, device, browser, os, country
- vitals: id, session_id, path, metric, value, at — largest contentful paint, cumulative layout shift, interaction latency, time to first byte
- releases: id, version, deployed_at

CRASH GROUPING
- Fingerprint from the exception type and the top frames of your own code, skipping framework and vendor frames
- **Normalise the variable parts out**: ids, numbers in paths, quoted values. Otherwise every affected user creates a new group
- Fingerprint on function and file, never on line numbers, or a whitespace change creates a hundred new groups
- Source maps uploaded per release and resolved on ingest, with both raw and resolved frames stored

REAL USER MONITORING, DONE LIGHTLY
- The browser's own PerformanceObserver reports the vitals. **You do not need to measure anything yourself** — read what the platform already provides
- Send once on page hide, in a single beacon. Never on an interval, and never blocking anything
- **Report percentiles, never averages.** The average page load is a number nobody experienced; the 75th percentile is what a bad visit looks like and it is what the metric is defined against
- Segment by device, connection and country, because 'the site is fast' is usually only true on a laptop in your own city

THE COMBINATION, WHICH IS THE POINT
- The session id on both the error and the vitals. Now 'the users hitting this error were also on the slowest pages' is one query
- On a group page, show the distribution of the vitals for the sessions that hit it
- **A release comparison: errors and vitals before and after a deploy, side by side.** That single view answers the only question anybody asks after shipping

INGEST SAFETY
- Accept, write, respond. A rate limit per group so a hot loop costs a counter and not a disk
- Payload and stack depth caps
- Scrub secrets and never store input values or personal data from the page

ALERTING
- New group, regression of a resolved group, spike against a group's own baseline, and a vitals regression after a release. A daily digest for everything else

WHAT MATTERS MOST
A shared session id, percentiles rather than averages, and the release comparison. Together they turn two separate tools into one answer.