Sentry — what it is, principles and error collection

What is Sentry in Development

Sentry is an open-source crash reporting and performance monitoring platform founded in 2012. It allows developers to receive real-time error notifications with full diagnostic context: call stack, variable values at the moment of crash, sequence of user actions before the error and environment state.

Unlike aggregated crash reporting services (Google Play Console, App Store Connect), which provide only statistics and basic charts, Sentry shows each event individually with the ability to group by error type and filter by app version. An Issue in Sentry is a group of events with the same stack trace, allowing you to not drown in thousands of identical crashes but focus on fixing the root cause with full context.

According to Sentry (2025), the average error detection time is reduced from 30 minutes to 30 seconds after implementing Sentry SDK, and diagnosis time is reduced by 60% thanks to automatic breadcrumbs and environment context. The platform is used by over 100,000 organizations worldwide, including Airbnb, Microsoft, Instagram and PayPal, processing billions of events daily.

Sentry Architecture: SDK, Relay and Event Processing

The Sentry system consists of three main components: SDK on the application side, Relay (proxy server) and event processing backend. Sentry SDK is a library embedded into the application that intercepts exceptions, collects context and sends events to Relay via JSON/HTTPS protocol.

Sentry Relay

Relay is an intermediate server that can be deployed in the company's infrastructure. It receives events from SDK, filters them according to rules (PII data, unnecessary events), buffers and forwards to Sentry SaaS or a self-hosted instance. Relay ensures low latency — typical event receipt time is 500–1500 ms.

Inbound Data Filter

Sentry provides built-in filters to discard unwanted events before they are sent to the server: errors from test environments, errors from old app versions, duplicate events with the same fingerprint. Filtering saves up to 70% of data volume in a typical production project, reducing consumption costs and device communication channel load.

Setting Up Sentry SDK for iOS and Android

Installing Sentry SDK for mobile platforms takes 5–10 minutes and requires adding a dependency and initialization with a DSN key. DSN (Data Source Name) is a unique project identifier in Sentry that specifies where to send events.

Setup on Android

For Android, Sentry provides automatic instrumentation through a Gradle plugin. The plugin modifies bytecode at compile time, adding wrappers for all Activities, Fragments and network calls. Auto-instrumentation is enabled with a single option in build.gradle and allows you to get breadcrumbs from the application lifecycle without changing code.

import io.sentry.Sentry

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Sentry.init { options ->
            options.dsn = "https://example@sentry.io/project"
            options.tracesSampleRate = 0.2
            options.enableAutoSessionTracking = true
        }
    }
}

The code initializes Sentry SDK in an Android application. The parameter tracesSampleRate = 0.2 enables performance tracing for 20% of sessions, enableAutoSessionTracking automatically creates sessions for each app launch.

Setup on iOS

The iOS SDK supports CocoaPods, Swift Package Manager and Carthage. After installation, the SDK automatically intercepts NSException, signals (SIGABRT, SIGSEGV) and Swift errors. Sentry Cocoa SDK is compatible with iOS 12+ and macOS 10.13+, supports Swift Concurrency (async/await) and automatic instrumentation of URLSession.

import Sentry

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        SentrySDK.start { options in
            options.dsn = "https://example@sentry.io/project"
            options.enableAutoPerformanceTracing = true
        }
        return true
    }
}

The Swift code activates Sentry SDK with automatic performance metric collection. enableAutoPerformanceTracing enables monitoring of screen load time and HTTP requests without additional code.

Breadcrumbs and Error Context

Breadcrumbs are a chronological sequence of events preceding an error. Sentry automatically records breadcrumbs for button presses, screen transitions, HTTP requests and system notifications. Developers can add custom breadcrumbs for business logic.

Each breadcrumb contains a timestamp, event type (navigation, http, ui, error), category and arbitrary data. When an error occurs, all breadcrumbs from the last 2–5 minutes (configurable) are attached to the event. This context is often more important than the stack trace itself: the developer can see that the user clicked “Pay” after selecting a product, and only then the crash occurred. The maximum number of breadcrumbs by default is 200, after which the oldest records are automatically removed.

Sentry.addBreadcrumb(
    Breadcrumb().apply {
        category = "payment"
        message = "User tapped Pay button"
        type = "user"
        level = BreadcrumbLevel.INFO
        data["amount"] = "19.99"
        data["currency"] = "USD"
    }
)

The code adds a custom breadcrumb for a user action in the payment scenario. If an error occurs after this action, the developer will see in Sentry that the user clicked “Pay” with the amount of 19.99 USD, allowing quick localization of the problem in the payment flow.

User Context

Sentry allows attaching user information to events: ID, username, email. User context is automatically passed with all events from the same session, allowing errors to be grouped by users and determining how many users were affected by a specific bug. It is important to follow the privacy policy and not transmit personal data if it is not permitted by the application's policy.

Source Maps and Debug Symbols

In production builds of iOS and Android, code is usually minified or obfuscated. Without processing, the error stack will contain incomprehensible names like “a.b()” instead of “UserViewModel.fetchData()”. Source maps (JavaScript) and debug symbols (dSYM for iOS, ProGuard mapping for Android) restore a readable stack.

For Android, Sentry automatically uploads ProGuard mapping files via the Gradle plugin during release build. For iOS, dSYM files need to be uploaded — Sentry provides a script for automatic upload during archiving. Without debug symbols, the error stack in Sentry will be useless for the developer, so the process of uploading them should be a mandatory step in the CI/CD pipeline.

Performance Monitoring with Sentry

Since version 2020, Sentry includes performance monitoring — collecting transaction execution time metrics with distributed tracing. A Transaction in Sentry is a measurable unit of work: screen load, API request execution, background task processing. Each transaction contains child spans that show which specific steps took the most time.

Performance monitoring in Sentry is integrated with error tracking: if a transaction ends with an error, the corresponding span is marked with the “error” status, and the developer can navigate from performance metrics to exception details. Trace ID links all events (errors, transactions, breadcrumbs) into a single session for end-to-end analysis, providing seamless transition between Issues and Performance tabs in a single Sentry dashboard.

According to Sentry Performance Benchmark (2024), an application with performance monitoring enabled (10% sampling rate) consumes 2–5% more traffic and 1–2% more CPU resources on the device. This overhead is compensated by a 70% reduction in performance diagnosis time compared to manual profiling.