GlitchTip

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 tracking that replaces a hosted GlitchTip: my applications report exceptions, they group sensibly, and I hear about the ones that matter.

Read this first: GlitchTip is open source and self-hosting it is free — the fee buys a hosted instance with backups and upgrades. Build this when you want error tracking that is exactly as heavy as you need, and note the trick that makes it cheap: speak the Sentry protocol, and every existing SDK points at you unchanged.

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

THE DATA MODEL
- projects: id, slug, name, platform, public_key, is_active, retention_days
- issues: id, project_id, fingerprint, title, culprit, level, status, first_seen_at, last_seen_at, event_count, user_count, assignee, resolved_in_release, snooze_until
- events: id, issue_id, event_id, timestamp, release, environment, level, message, exception_json, stacktrace_json, breadcrumbs_json, request_json, tags_json, user_hash, sdk, received_at
- releases: id, project_id, version, created_at, deployed_at, commits_json
- artifacts: id, release_id, name, path, sha256 — source maps
- comments, activity: the history of an issue, append-only
- alert_rules: id, project_id, condition_json, channels_json, throttle_minutes
- Events are the bulk of the data and the thing that must expire. Keep the issue forever and the events for a stated window

THE INGEST ENDPOINT
- Speak the Sentry store and envelope protocol. This single decision means every official SDK, in every language, works without writing a client
- Authenticate with the public key from the DSN, per project
- Answer in a couple of milliseconds: validate, enqueue, return. Parsing and grouping happen in the worker
- 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 it is needed
- A payload size cap, and gzip and deflate accepted
- Idempotency by event id, so an SDK's retry does not double-count

GROUPING, WHICH IS THE ENTIRE VALUE
- A fingerprint from the exception type plus the stack frames that belong to your own code, ignoring library frames — that is what makes the same bug from twenty places one issue
- Normalise the variable parts out of the message: numbers, identifiers, addresses, paths. 'User 4821 not found' and 'User 9932 not found' are one issue
- Respect an explicit fingerprint from the SDK when the caller sets one
- Merging two issues by hand, and splitting one, both recorded
- Get this wrong and you have either one issue containing everything or ten thousand issues containing one event each. Both are unusable, and this is where the time should go

WHAT AN EVENT CARRIES
- The full stack trace with source context around each frame, the local variables where the SDK sends them, and your own frames marked
- Breadcrumbs: the recent log lines, requests and clicks that preceded it, which is usually what actually explains the error
- The request: method, path, headers with authorisation and cookies redacted, and the body only if the project opts in
- Tags for release, environment, server, browser and anything the SDK adds, all filterable
- A user identifier hashed with a salt, so 'how many people hit this' is answerable without storing who they are

SOURCE MAPS
- Uploaded per release from CI with a token
- Applied at read time rather than at ingest, so a map uploaded after an event still fixes it
- A clear message when a map is missing or does not match, because a minified stack trace is no stack trace at all

ALERTING WITHOUT NOISE
- Rules: a new issue, a regression of a resolved one, a rate above a threshold, an issue affecting more than N users
- Throttled per rule so one bad deploy sends one alert rather than nine hundred
- Channels: email, webhook, chat
- Resolve, ignore, and snooze until a condition — snoozing until it happens again in a new release is the setting people actually want
- A regression reopens the issue and says which release it came back in

RETENTION
- Events expire on a stated schedule and the sweeper actually deletes them
- Issue-level counts survive expiry, so history is not lost with the payloads
- Disk watchdog that sheds ingest rather than filling the volume

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

WHAT MATTERS MOST
Grouping and the fast ingest. Build the fingerprint algorithm against a few thousand real errors and tune it until the issue list is something you would actually read every morning. Then make sure the endpoint stays up under a flood, because the day it matters is the day everything is on fire.

Give me the repository, migrations, .env.example, a seed of real-shaped events, and a README with deploy steps behind Caddy and the DSN to point an SDK at.