Read stack traces

A stack trace is the path the application took before an error was captured. Reading it well helps you move from a symptom, such as a failed request or job, to the code path that likely needs investigation.

What a stack trace shows

Each stack frame identifies one point in the call path. Frames usually include a file, function or method name, line number, and sometimes nearby source code. Errorgap shows these frames inside the error group so your team can inspect the failure without switching tools immediately.

• Error type describes the class or category of failure.
• Error message describes what the runtime reported.
• Frames show the code path that led to the error.
• Source context shows nearby code when available.

Read from top to bottom

Start near the top of the stack trace to understand where the error surfaced, then scan down until you find the most relevant application frame. The first line is not always the root cause, but it usually tells you what failed.

If the top frames are framework or library code, continue until you find code owned by your application. That is often the best starting point for investigation.

Focus on application frames

Application frames are the frames your team can change. They usually contain your project paths, package names, route handlers, jobs, components, or service modules. Framework frames are still useful context, but they are usually not where the fix belongs.

• Look for the first frame in code your team owns.
• Check whether the frame points to request handling, background work, or startup code.
• Compare repeated occurrences to see whether they fail in the same code path.
• Use the selected frame as the anchor for opening linked source or creating an issue.

Use source context

Source context shows nearby lines around a selected frame when Errorgap can resolve them. Use it to understand the condition, input, or branch that may have triggered the error.

If source context is missing, the stack trace can still be useful. Use the file path, function name, line number, release, and repository search to find the related code.

Check request context

Runtime and request context can explain why a code path failed. Review the context panel for values that clarify impact or reproduction steps, while treating sensitive fields carefully.

• Route, URL, job, or command names can identify the affected workflow.
• Environment and hostname can show where the failure happened.
• Runtime details can distinguish browser, server, worker, or scheduled-job failures.
• Sanitized request values can help reproduce the failure without exposing private data.

Connect to a release

Release values help answer whether the error appeared after a deploy. Compare the first seen time, last seen time, and release value against recent changes before assigning the fix.

• Check whether the group first appeared after a specific release.
• Look for repeated occurrences on the same release.
• Use deploy context to identify likely code changes.
• Watch the group after a fix ships to confirm occurrences stop.

What to share with teammates

When handing off an error, include the context someone needs to start without repeating your triage work.

• The error group link and current state.
• The relevant application frame and source line.
• The affected environment, release, and workflow.
• Any request or runtime context that explains impact.
• Your best guess at whether this is new, regressed, or known noise.

Include links to supporting evidence when they matter: nearby logs, slow routes or queries, host or volume pressure, monitor failures, and replay sessions.