Monitoring: Part 6 — Application Errors: Sentry and GlitchTip

Server metrics and logs don’t show everything. If an error occurred in the user’s browser or in a rare code path, the server may not log anything and the user may simply close the page. For such cases there are application error tracking systems: they receive the exception directly from the code along with the stack trace, release version, and request context, and they group identical errors into a single issue.

The best known of these is Sentry. Its open alternative, compatible with the same client libraries, is GlitchTip.

What an error tracking system gives you

• Stack trace with the exact location in code, including for minified JavaScript if source maps are uploaded.
• Grouping. A thousand identical exceptions — one issue with a counter, not a thousand emails.
• Context: browser, operating system, release version, page URL, sequence of events before the crash (breadcrumbs).
• Release association: you can see in which version the error appeared and whether it was fixed in the next release.
• Alerts about new errors and sharp increases in existing ones.

This is not a replacement for metrics and logs: Prometheus or Zabbix will tell you whether the server is alive and has enough resources, while Sentry will tell you what exactly broke in the code. An overview of metrics and alerts is in the first part of the series.

Sentry: cloud or self-hosted

Cloud Sentry (sentry.io). As of September 2026 the free Developer tier is for a single user and includes 5,000 errors and 5 million tracing spans per month. The Team tier for a team starts at $26/month when billed annually. You can’t pay a foreign service with a Russian card: Visa and Mastercard have not worked outside Russia since March 2022.

Sentry on your own server. The Sentry source code is distributed under the FSL-1.1-Apache-2.0 (Functional Source License). You can use and modify it for your own needs; building a competing service on top of it is prohibited; two years after release each version automatically switches to Apache 2.0. This is not an open license in the strict sense, but for internal use there are practically no restrictions.

A ready self-hosted build is the getsentry/self-hosted repository. Documentation requirements: 4 CPU cores, 16 GB RAM plus 16 GB swap (32 GB recommended), at least 20 GB disk, recent Docker and Docker Compose. It runs several databases and a message broker, so disk speed matters. For a small project this is heavy.

GlitchTip: a lightweight open alternative

GlitchTip is an open error-tracking system under the MIT license. It accepts events from Sentry client libraries, so the only code change is the DSN address. GlitchTip has a cloud version with a free tier up to 1,000 events per month, but its main advantage is ease of self-hosting: a few containers (web app, background workers, PostgreSQL, Redis) instead of dozens.

GlitchTip has fewer features: it lacks some performance analysis tools and session replay found in Sentry. For the task of “learning about errors and seeing stack traces” this is usually enough.

Integrating the SDK

The process is the same for Sentry and GlitchTip: create a project, copy the DSN — the address to which the library sends events — and initialize the SDK as early as possible when the application starts.

JavaScript in the browser. Tracing is included in the main package; the separate @sentry/tracing is no longer needed:

npm install @sentry/browser --save

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
  release: "my-app@1.4.2",
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 0.1,
});

Python (Django, Flask, FastAPI are picked up automatically if installed):

pip install sentry-sdk

import sentry_sdk

sentry_sdk.init(
    dsn="https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
    release="my-app@1.4.2",
    traces_sample_rate=0.1,
)

The value tracesSampleRate: 1.0 from the documentation examples means recording every request. For production workloads 5–10% is usually enough, otherwise your tracing quota will be exhausted in a few days.

Checking the integration is simple: throw a test exception in the code and make sure the event appears in the UI.

Source maps and releases

Frontend code in production is minified, and without source maps the stack trace points to line 1 of main.8f3a.js. The simplest way to set up uploading source maps is the wizard:

npx @sentry/wizard@latest -i sourcemaps

It will add uploading of maps to the build via the Sentry CLI. The association between maps and files is built by debug identifiers (Debug IDs), so you don’t need to change built files manually. The release version in release must match what the build knows — then you can see in the UI in which version the error appeared. Uploading maps and creating the release should be done in the CI pipeline, not from a developer machine.

Alerts

Alerting on every error quickly becomes noise. A practical set of rules:

• about a new error that hasn’t happened before;
• about a sharp rise in the frequency of a known error;
• about a regression — an error marked as fixed that reappears.

Channels — email, messengers, webhooks. The principles are the same as for infrastructure alerts: notify only about things that require action.

Personal data in events

An error event easily carries personal data: an email address in query parameters, IP address, form contents. For a Russian company this is an issue not only of security but of law: since July 1, 2025 primary recording of personal data of Russian citizens must be kept in databases on Russian territory (details — in the article about 152-FZ). Sending events containing such data to a foreign cloud contradicts this requirement.

What to do:

• do not enable sending personal data by default (send_default_pii in Python and the analogous setting in JavaScript should remain off);
• scrub sensitive fields before sending in the beforeSend / before_send handler;
• enable server-side data scrubbing in the project settings;
• if data in events is unavoidable — host GlitchTip or Sentry on your own server in Russia.

Common mistakes

• Sampling 100% of traces in production — the quota runs out and the extra data is useless.
• No source maps — frontend stack traces are unreadable.
• Release version not passed — it’s unclear whether the error is fixed.
• DSN with write permissions checked into a public repo of server code. The frontend DSN is public by design, but server-side DSNs are better passed via environment variables.
• Alerting on every event — after a week they stop being read.
• Personal data is sent to a foreign cloud along with the stack trace.