Investigating Production Errors with Sentry: A Practical Guide

Investigating Production Errors with Sentry: A Practical Guide

Sentry is an application monitoring platform that captures errors and performance data from your code. Its value shows up when a new error appears and someone has to answer one question fast: did we cause this, or did something else? This guide walks through reading Sentry evidence, separating a deployment regression from an infrastructure fault or a long-standing defect, and confirming the cause before anyone touches production.

TL;DR

• Problem: a spike in Sentry issues rarely says why it happened. The same stack trace can come from a bad release, a failing dependency, a saturated node or a bug that has been there for months.
• Takeaway: treat every spike as a set of hypotheses. Test them in parallel against release, deployment, infrastructure and history evidence, and write down what each test showed.
• Method: start in Sentry (first seen, affected releases, release health, stack trace), then confirm against deploy timelines, Kubernetes state, cloud metrics and repository changes.
• Next step: use the checklist and troubleshooting table below. To pull the surrounding evidence together without leaving a read-only workflow, see the Opsphere Sentry integration.

Table of Contents

• What Sentry shows you, and what it cannot
• The four usual causes of a new error spike
• Step-by-step investigation workflow
• Verification conditions before remediation
• Troubleshooting table
• Where a read-only operational layer fits
• Opsphere plans
• A worked example: spike after a Friday release
• Making the workflow routine
• FAQ
• Next step
• Sources

What Sentry shows you, and what it cannot

Sentry groups related error events into issues. According to the Sentry documentation on issues, an issue is a group of events that share the same root cause, so one bug can be tracked across hundreds of occurrences instead of hundreds of separate alerts. Each issue has a stack trace, the sequence of function calls that led to the error, with your own code highlighted and framework frames collapsed.

Sentry also connects to source control. Its documentation describes how it compares stack trace file paths against repository commits to surface a suspect commit, with the author and diff.

That is strong evidence about the application layer. It is not the whole picture. Sentry sees what the code reports. It does not see why a pod was rescheduled, why a database failover happened, or what else shipped to the cluster in the same ten minutes. A clean investigation uses Sentry as the starting point, then asks the systems around it to confirm or reject each explanation.

Google Cloud’s engineers make the same point about monitoring in general: combining client-side, network and server-side signals gives the context needed to find the root cause of performance bottlenecks and application errors. Treat that as the design principle for everything below.

The four usual causes of a new error spike

Nearly every new spike falls into one of four buckets. Naming them up front keeps the investigation from anchoring on the first plausible story.

1. A recent deployment. New code, a changed dependency version or a build configuration change introduced a defect.
2. An application change that is not a deploy. A feature flag flip, a config value, a schema migration or a changed upstream API contract altered behavior without a new release.
3. An infrastructure issue. Resource exhaustion, a network fault, a failing node, an expired certificate or a dependency outage produces errors in healthy code.
4. An existing defect that surfaced. An old bug was always there, but traffic shape, a new customer, a new client version or a data edge case exposed it at volume.

The workflow below is built to eliminate these one at a time, with evidence for each elimination.

Step-by-step investigation workflow

Step 1: Define the spike precisely

Before opening a stack trace, fix the scope. Write down:

• The issue or group of issues involved, and whether the issue is new or reopened.
• The start time of the spike, to the minute if the graph allows it.
• Environment (production, staging), and whether the spike is in one region, one service or everywhere.
• Event count and, more importantly, the number of affected users, since one retry loop can inflate events from a single client.

A spike that is steep and starts at a clean timestamp points toward a discrete change such as a deploy, a flag or a failure. A slow rise points toward load, data growth or a leak.

Step 2: Check first seen, last seen and issue age

On the issue page, find when the issue was first seen. This single field splits the problem in half.

• First seen is minutes before the spike: the cause is new. Continue to deploy and change evidence.
• First seen is weeks or months ago: it is an existing defect. Ask what changed in volume or exposure, not what changed in code.
• The issue was resolved and reappeared: check whether it was marked resolved in a release and whether that release actually contained the fix. A regression of a fixed issue usually points to a revert, a bad merge or a second code path.

Also check for grouping effects. If a code change altered the stack trace shape, an old error can reappear as a brand new issue. Compare the message and the failing function against recently resolved issues before concluding it is new.

Step 3: Compare affected releases

Open the issue’s release breakdown. The question is whether the errors cluster in one release or spread across several.

• Only the newest release is affected: strong signal for a deployment regression. Confirm the release is the one that started receiving traffic at the spike time.
• Several releases are affected at similar rates: the cause is probably not the newest code. Look at shared dependencies, infrastructure and data.
• Old releases still running spike too: a deploy is unlikely to be the cause. Mixed fleets, like rolling updates or mobile clients on old versions, make this a very useful test.

Be careful with rolling deployments. During a rollout, both versions serve traffic. An error in the new version shows as a small share of events that grows as the rollout progresses. A flat share across versions argues against the release.

Step 4: Read release health and session adoption

Raw event counts depend on traffic. Release health puts them in context. Sentry’s documentation explains that a session represents a user’s interaction with the application, and that sessions flagged for crashes, errors or abnormal exits feed derived metrics such as the number of users who did not experience a crash. It also tracks adoption of each release.

Two readings matter here:

• Adoption: what share of sessions are on the new release right now? A release with 3 percent adoption and a spike of errors is a very different problem from one at 80 percent. Low adoption with high error rate means the defect is concentrated and affects few users so far, which is a good moment to pause a rollout. High adoption means the blast radius is already wide.
• Crash-free sessions and users, release over release: compare the new release to the previous one over the same window. A drop that appears only in the new release supports the deployment hypothesis. A drop in both supports an environmental cause.

A caution on interpretation: adoption changes the denominator. A release that goes from 5 percent to 50 percent adoption will show more total errors even if its per-session error rate stays flat. Compare rates, not counts.

Opsphere has written about how it reads Sentry release health by session and how it handles project-level stats honestly in its release health update.

Step 5: Read the stack trace for the layer of the fault

The stack trace tells you where the error surfaced, which is not always where it started. Classify the top frames:

• Your code in a file touched by the release: likely regression. Check the suspect commit, then verify it by diffing the release.
• Framework or library frames, with your code only as the caller: a dependency upgrade or a changed input. Check lockfile changes in the release.
• Network, timeout or connection errors (connection refused, DNS failure, deadline exceeded): the application is reporting a symptom of an infrastructure or upstream problem. The trace is correct, but the cause is elsewhere.
• Out-of-memory, killed process or resource errors: look at the container and node, not the code.
• Data-dependent errors (null reference, parse failure on a specific field): often an existing defect exposed by new input. Check the tags and user segment for a pattern.

Tags and breadcrumbs help. Look for a shared value across events: one customer, one region, one browser, one feature flag state, one Kubernetes pod name. A strong skew toward a single value narrows the search quickly.

Step 6: Look at performance signals alongside errors

Errors and latency often move together. Check whether slow transactions rose before the errors started. If latency climbed first, timeouts may be producing the errors, which suggests a saturated dependency, a slow query or a resource limit. If errors rose without any latency change, a logic defect is more likely.

Compare the affected transaction with its baseline and see which span grew: database, outbound HTTP call or application time. A span that is slow in a downstream call moves the investigation to that downstream service.

Step 7: Correlate with deployments, Kubernetes and cloud state

Now leave Sentry and test the environmental hypotheses. For the spike window, gather:

• Deployment timeline: which CI/CD pipeline runs completed, which images were promoted, which rollouts started and finished, and whether any rollback occurred.
• Kubernetes state: pod restarts, OOMKilled events, failed readiness probes, HPA scaling, node pressure, evictions and recent changes to ConfigMaps or Secrets.
• Cloud infrastructure: load balancer error rates, database CPU and connections, queue depth, certificate expiry, and any provider incident in the region.
• Repository changes: merged pull requests, config changes and dependency bumps between the previous release and the current one.
• Observability data: metrics and traces for the dependencies named in the stack trace.

This is where teams lose the most time. Each source lives in a different console, and each has its own time zone, naming and filter model. The goal is a single timeline that places the Sentry first-seen timestamp next to every change and every infrastructure event around it. Network telemetry belongs in that timeline too, since combining frontend, backend and network telemetry is what lets teams trace a symptom to its actual root.

Step 8: Decide, then verify before remediation

By now one hypothesis should be strongest. Do not remediate yet. Run the verification conditions in the next section, then act through your normal change process.

Verification conditions before remediation

A fix applied to the wrong cause costs time and can mask the real problem. Before a rollback, a hotfix, a scale-up or a config change, confirm the conditions that belong to your hypothesis.

If you suspect a deployment:

• The first-seen time falls after the release started receiving traffic, not before.
• Errors concentrate in the new release and are absent or much lower in the previous one at the same time.
• The failing code path was changed in the release diff, or a changed dependency sits in the trace.
• The issue was not present in the previous release under comparable traffic.

If you suspect an application change that was not a deploy:

• No release explains the timing, but a flag change, config change or migration does.
• Errors correlate with a flag state, tenant setting or schema version tag.

If you suspect infrastructure:

• Errors appear across multiple releases, including older ones.
• Kubernetes or cloud metrics show a fault that begins at or just before the spike: restarts, saturation, failed probes, a dependency outage.
• Other services depending on the same resource show symptoms too.

If you suspect an existing defect:

• First seen predates the spike by a meaningful margin.
• A change in traffic, data or client mix coincides with the volume increase.
• The same stack trace appears in earlier releases with a lower rate.

Always confirm before acting:

• Two independent evidence sources agree, for example Sentry release data plus a deployment record.
• You can state what result would prove the hypothesis wrong, and you checked it.
• The proposed action is reversible, and someone owns the decision.
• The affected-user count justifies the action’s risk.

Troubleshooting table

Use this table as a quick map from what you observe to the likely cause and the next check.

Where a read-only operational layer fits

The slowest part of the workflow above is not reading Sentry. It is steps 7 and 8: pulling deployments, Kubernetes, cloud, CI/CD and repository evidence into one timeline while an incident clock is running.

Opsphere is built for that gap. It is a read-only operational intelligence layer that connects to the tools you already run and lets you correlate Sentry evidence with deployments, Kubernetes, cloud infrastructure, CI/CD, repositories and observability systems. It does not replace Sentry, store Sentry data, resolve errors automatically or make production changes. Your tools remain the source of truth, and your team keeps the decision.

In practice that means a few things:

• Parallel hypothesis testing. Deploy, infrastructure and history explanations are checked against their own evidence at the same time, instead of one console at a time.
• Evidence you can review. Each conclusion points back to the data behind it, which is what the verification conditions above require. See how evidence-backed investigations work.
• Access through MCP. Opsphere exposes read-only operational tools through Model Context Protocol, so you can query from an AI assistant or IDE. The MCP operational gateway page explains the model, and the security page covers how access is governed.

Opsphere plans

Opsphere publishes tiered monthly plans: Community at €0 per month, Developer at €19 per month, Team at €500 per month and Enterprise at €450 per month, plus Custom Solutions with no published price. Current details are on the pricing page.

Small SRE teams can begin with an entry plan and connect only the systems relevant to their current incident workflow.

A worked example: spike after a Friday release

Consider a realistic scenario, described generically.

A team sees a burst of a new TypeError in the checkout service at 14:07. The issue was first seen at 14:06.

1. Scope: production only, all regions, affected users in the low hundreds and rising.
2. First seen: one minute before the spike. The cause is new, so an old defect is unlikely.
3. Releases: the errors show up in the newest release and in the previous one at a similar rate. That weakens the deployment hypothesis.
4. Release health: the new release has modest adoption, and crash-free sessions are down in both versions. The problem is not release-specific.
5. Stack trace: the error is thrown while parsing a response from an internal pricing service. Your own code is only the caller.
6. Performance: latency on the pricing call rose a few minutes before the first error.
7. Environment: the pricing service’s pods began restarting at 14:03 after a memory limit was reached. A config change to that service merged earlier in the day.
8. Verification: two independent sources agree, Sentry’s multi-release spread and the pod restart record. A rollback of checkout would not help. The owner of the pricing service gets the evidence.

Without the cross-release check, the team might have rolled back a healthy release and lost twenty minutes. The structure of the workflow, not the tooling, is what prevents that.

Making the workflow routine

A few habits turn a one-time investigation into a repeatable practice.

• Tag releases consistently. Every deploy should create a release in Sentry with a version that maps to a commit and a pipeline run.
• Connect source control. Suspect commits only help if repositories are linked and the SDK reports accurate file paths.
• Record deployment events. A deploy marker in your timeline is the cheapest evidence for or against a regression.
• Capture the hypothesis log. Write each hypothesis, the evidence checked and the result in the incident channel. It speeds up handoffs and the post-incident review.
• Review adoption before a rollout widens. If release health shows a problem at low adoption, pause the rollout through your normal process.
• Keep ownership clear. Map services to teams so the evidence goes to the right owner the first time.

FAQ

How do I know if a Sentry error was caused by a recent deployment?

Check whether the issue’s first-seen time falls after the release started taking traffic, and whether errors concentrate in the new release rather than the previous one. Then confirm that the failing code path or a dependency changed in the release diff. If older releases show the same errors at the same time, look at infrastructure instead.

What is release health in Sentry?

Release health tracks how each release behaves in production using session data. According to the Sentry documentation, it covers user adoption, usage, crash percentages and session data, so you can see the impact of crashes and bugs on users. It is most useful for comparing a new release with the one before it.

Can Sentry tell me the root cause of an error?

Sentry gives strong application-level evidence: the stack trace, affected releases and a suspect commit. The root cause may sit outside the application, such as a failing node or a downstream outage. Confirm it against deployment, Kubernetes and cloud data before changing anything.

Does Opsphere replace Sentry or change anything in production?

No. Opsphere is a read-only layer that correlates Sentry evidence with deployments, Kubernetes, cloud infrastructure, CI/CD, repositories and observability systems. It does not store Sentry data, resolve errors automatically or make production changes.

Next step

If your team already uses Sentry and spends incident time hopping between consoles, connect the evidence in one read-only workflow. Start with the Opsphere Sentry integration, then pick the plan that matches your team size.

Sources

• Sentry documentation: Release health
• Google Cloud Blog: Using Sentry to monitor web and mobile apps
• Top Network Monitoring Techniques 2025

Recommended

• Evidence-Backed Operational Investigations
• GitHub in Production: Trace Incidents to Code Changes
• Prometheus Monitoring: How It Works and Where Teams Hit Limits

This article is provided for general informational purposes only and does not constitute professional, legal, security, or compliance advice. Please evaluate recommendations against your organization’s specific environment and requirements.