DEV Community

BugIt
BugIt

Posted on Originally published at bugit.hashnode.dev

What to paste from a crash log (and what to leave out)

#debugging #softwareengineering #testing

"Logs attached." Two words that appear in a great many bug reports, followed by a file of several thousand lines that nobody opens. The log was supposed to be the strongest evidence in the ticket. Instead it became homework.

A developer does not need the whole log. They need the few lines that explain what went wrong, and enough around them to trust those lines. Here is how to find them.

Start from the end, then walk back

Most crashes announce themselves near the bottom. Look for the last exception or error line: the type (NullReferenceException, TypeError, SIGSEGV) and its message. That pair is the headline of your report.

Then read upward until the noise starts. You are looking for:

  • The exception type and message, exactly as written.
  • The top stack frames: the first five to ten lines of the trace, which name the function and the file where it failed.
  • The line it came from in your own code, as opposed to the framework or the runtime.
  • One or two lines before it: the request, the action or the state change that led there.

That is usually fifteen to thirty lines. Paste those into the ticket as text, inside a code block, and attach the full log as well for anyone who wants to dig.

What to leave out

  • Repeated warnings that also appear on a healthy run. If the log says it on a healthy run too, it is probably not your bug.
  • Unrelated subsystems. Heartbeats, cache hits, analytics pings.
  • Anything private. Logs are where email addresses, session tokens, API keys and customer details collect. Read the lines you paste and remove them first. A bug tracker is often readable by the whole company, and many trackers cannot truly delete an issue.

Say what the log does not show

If the log is truncated, rotated or missing the moment of the crash, say so in the ticket. "The log starts after the crash; the app restarted itself" is useful evidence. A silent gap invites a developer to assume the lines you pasted are the whole story.

Also say where the log came from: which device, which build, which time zone. A timestamp with no zone sends people to the wrong minute.

A small template for the evidence section 

Evidence
  Exception: TypeError: Cannot read properties of undefined (reading 'total')
  Top frames:
    at applyDiscount (src/billing/discount.ts:88)
    at recalcCart (src/billing/cart.ts:142)
    at onPlanChange (src/billing/plan.ts:57)
  Before it: user switched plan from monthly to annual with coupon SAVE20
  Full log: attached (app-2026-10-07.log, 4,102 lines; crash at line 3,977)
  Not in the log: the restart that followed
Enter fullscreen mode Exit fullscreen mode

How BugIt helps with this

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. Paste a crash log into the conversation and BugIt keeps the exception, the message and the top stack frames for the draft ticket, instead of dumping the whole file into it. If a log is too large to scan, it says the log was truncated rather than cutting it silently.

Before filing, it also redacts email addresses, tokens, API keys and similar data from the ticket text. That redaction is pattern based, so read the draft before you approve it. Nothing is filed until you have read the draft and typed FILE IT.

The 30 second film:

Paste the crash log, keep the line that matters

Try BugIt

Top comments (0)