Sentry

Sentry is the primary observability tool for every Total Ventures product, offering a unified view of errors and performance issues across web and native mobile applications, crucial for agentic engineering workflows.

What it is

Sentry is an error tracking and performance monitoring platform. It automatically captures unhandled exceptions, network errors, and UI freezes, providing detailed context for each event. This context includes user information, device details, browser specifics, and the release version the error occurred in. For native applications, Sentry handles symbolication, turning cryptic memory addresses into readable code paths. Its session replay feature allows me to visually reconstruct user interactions leading up to an error, offering a level of insight that stack traces alone cannot provide.

How I use it

For web properties like Total Formula 1 and Pregnancy Power Hour, Sentry monitors frontend JavaScript errors and performance regressions immediately after deployments. I tag errors by their respective release versions, which allows for quick identification of new issues introduced by recent code changes. The session replay feature is invaluable for debugging user-reported issues, letting me see exactly what steps a user took. On the native side, for the Inky iOS app, Sentry provides robust crash reporting with symbolicated stack traces. This is critical for debugging Swift and Objective-C issues, especially when dealing with complex memory management or third-party SDKs. It integrates well with my Tuist setup, ensuring that dSYMs are correctly uploaded for symbolication. My agentic engineering workflows leverage Sentry alerts; critical errors can trigger an automated debugging process where AI agents gather context, analyze logs, and even draft potential fixes, significantly reducing manual triage time. Sentry also integrates with my deployment pipeline on Vercel for web apps, automatically associating errors with specific deployment IDs. This allows me to correlate a code change with new errors almost instantly. Performance monitoring helps identify bottlenecks, for instance, flagging slow image transformations from Cloudinary or sluggish API responses.

Why this over alternatives

Sentry's unified platform for both web (JavaScript, React, Next.js) and native (Swift/Objective-C) applications is a key differentiator. Managing observability across different tools for different platforms adds unnecessary complexity to a solo operator's stack. The out-of-the-box symbolication for iOS crashes is particularly strong; I learned the hard way that reliable dSYM management across various build systems is not trivial. The release health features, which show error rates per release and allow for comparisons, are essential for shipping today. This enables me to quickly assess the stability of a new release and initiate a rollback if necessary. While not perfect, session replay often provides the missing context needed to reproduce and fix bugs that are otherwise difficult to diagnose from stack traces alone. The developer experience with its SDKs across various frameworks is also consistently solid.

Where it falls short

Sentry's cost can become a consideration at high event volumes, particularly with extensive session replay usage. I manage this by implementing aggressive sampling for replays and filtering less critical errors to keep the bill predictable. Alert fatigue is another common challenge; default settings can be noisy, requiring careful configuration and tuning to ensure that only actionable issues trigger notifications. While session replay is powerful, it sometimes misses specific DOM interactions or complex state changes, meaning some issues still require deeper logging or manual reproduction. For native applications, initial setup for symbolication and bitcode handling can still be a multi-step process, especially when working with custom build systems or monorepos, despite Sentry's efforts to streamline it.