Confirm that the error is one problem
A release and an error spike can happen at the same time for different reasons. The release may contain the defect. A feature flag may have changed. A dependency may have failed. More traffic may have reached an existing fault. Treat the release as a useful time marker, not a verdict.
Start with the grouped issue, not the raw event list. A group gives you the exception type, message, stack frames, first seen time, last seen time, and event count. Check the first seen time against the release time. Then check the release label on the first and latest events.
A useful candidate regression has three facts: the issue was absent before the release, it first appeared after the release reached users, and new events carry the expected release label and environment. If an issue appeared before the release, the release did not introduce it. It may still have increased the event rate.
Check whether the sample can support the comparison
An event count alone does not show impact. Compare equal periods before and after the release. Keep the source and environment the same. Check error events first. Then check Monitor results and Measure traffic for the same period, if you use those tools.
Ask whether errors increased after the release, whether traffic changed by a similar amount, and whether an uptime incident overlapped the release window. Error growth with stable traffic supports a product regression. Error growth with matching traffic may show an existing fault that reached more users. An overlapping upstream outage can explain both errors and failed checks.
Observe groups errors. Monitor records checks and incidents. Measure records aggregate traffic. Each signal can support a diagnosis, but none proves one by itself. Warning: do not compare an incomplete after period with a full before period.
Read the stack trace where the program failed
Open a recent occurrence in the issue. Read the exception type and message. Then find the first stack frame from your application code. That frame is usually the best place to begin.
A JavaScript production stack can name a generated file and compressed line number. Upload the source map for the same release before matching errors arrive. Symbolication happens during event ingest, not retroactively. Name the artifact with the generated bundle basename plus .map, such as app-abc123.js.map for app-abc123.js. A different filename leaves the frame unchanged. The ECMA-426 source map specification describes the mapping from generated positions to source representation.
Read request data, tags, breadcrumbs, and the full payload only when they answer the current question. Write one testable hypothesis, such as a missing account value passed to checkout when a flag is enabled. A testable sentence is better than saying that the release broke checkout.
Reproduce the smallest failing case
Use the stack frame, error message, and event context to create one focused check. Run it against the release code or a safe local copy. Keep the test close to the failing input.
Mark the result clearly. Reproduced means the check fails with the reported condition. Not reproduced means the current evidence does not support the hypothesis. Cannot test means a required dependency or production state is missing. Do not call a release the cause when the test cannot reproduce the fault.
When you have a known good release and a known bad release, Git can reduce the commit range. Git bisect uses binary search between those endpoints. Use it only with a reliable test. An unstable test can produce a false first bad commit.
Fix, verify, and close the loop
Deploy the fix with a new release label. Inspect the existing issue in the PostDeploy console. Confirm that new occurrences stop or decline in the new release window.
Resolve the issue through a connected MCP client only after the evidence supports the fix. A new matching event automatically reopens a resolved or ignored issue and marks a regression. Compare that new occurrence with the original hypothesis.
Record the final cause through the issue comment action in a connected MCP client. Include the triggering condition, the change that fixed it, and the verification you ran. Observe records grouped errors, release labels, stack traces, release artifacts, and aggregate crash-free session data. It does not ingest logs, collect traces, compute application metrics, or record session replay.
Questions
Does a release label prove the release caused an error?
No. It provides timing and context. Reproduce a narrow hypothesis before you assign cause.
What should I compare with an error spike?
Compare equal time windows, the same source and environment, traffic, and overlapping uptime incidents.
Can Observe replace logs or tracing?
No. Observe records errors and release context. Use logs or tracing when the captured error context cannot explain a dependency failure.
What PostDeploy does not do here
- Observe does not ingest logs.
- Observe does not collect traces, metrics, or session replay.
- A recorded release label does not prove that the release caused an error.
Sources
Links support the technical facts and product boundaries described above.
- Git bisect documentation Checked
- ECMA-426 Source map format specification Checked