WoluTools
Find a tool

Developer tool · runs in your browser

Find the line in a stack trace that points to your bug

Paste a stack trace or error log into the field below. The reading updates as you type: the error in plain language, your own frames marked apart from library lines, and the likely causes ranked.

Your stack trace

Sample loaded

The reading

Updates as you type

A reading, not a diagnosis. It comes from the pasted text alone. The page cannot see your source, your dependency versions or the state of the process, so the ranked causes tell you where to look first.

Open the full-page workspaceThe same tool on its own page, with notes on how frames are classified and how caused-by chains are read.

You pasteA stack trace or an error log, as text
You getYour frames marked, the exception explained, causes ranked, one line to check first
You keepThe reading, copied or saved as a Markdown file

One clear job, from paste to reading

  1. 1

    Paste the trace

    Copy the whole thing, including the lines above the first frame. The exception message and any log context around it often carry more information than the frames themselves. Obvious credentials are replaced with placeholders before a single line is parsed.

  2. 2

    Read the split

    Frames are grouped into your code, third-party libraries and the runtime. The exception type is explained in ordinary words, and any caused-by chain is unwrapped so you can see which failure triggered which.

  3. 3

    Open the file it points at

    You get a ranked shortlist of causes and one concrete thing to check first, tied to a file and a line number. From there the work is yours — the tool does not change code and never sees your repository.

Finding your own code in a long stack trace

What you paste

You paste a stack trace or error log as text. Java and the other JVM languages, Python, JavaScript and Node, .NET, Go and PHP are recognised; the language is detected from the text, or you pick it. Copy the lines above the first frame too, because the message and log context often say more than the frames. Obvious secrets such as bearer tokens, API keys and connection strings are replaced with placeholders before analysis. All of this happens in your browser.

What you get back

You get the exception explained in ordinary words, with frames grouped into your code, third-party libraries and the runtime. Any caused-by chain is unwrapped, so you can see which failure triggered which. The highest frame from your own package is marked, since that is usually where you can make a change. You also get a ranked shortlist of likely causes and one thing to check first, tied to a file and line.

What stays your job

The tool reads only the text you paste. It cannot open your repository, check dependency versions or see variable values at the moment of the crash. The ranked causes are informed guesses about where to look, not a diagnosis, and it does not change code. Pattern matching for secrets is not perfect either. Internal hostnames, customer identifiers and absolute paths can still be sensitive, so read the trace before you paste it.

Questions before you run it

Is the trace sent to a server?

No. The trace is parsed by this page in your browser and is not uploaded or stored. That is also why there is no daily job count here: nothing runs on a server, so there is nothing to count and no result that expires.

Which languages and runtimes can it read?

Java and the other JVM languages, Python, JavaScript and Node, .NET, Go and PHP. The language is detected from the text. If detection fails, pick one of the six parsers from the language menu. Traces from other runtimes are not recognised, and forcing a parser on them gives an unreliable split between your code and library code.

Does it fix the error?

No. It reads the text you paste and nothing else. It cannot open your repository, check your dependency versions or see the runtime state at the moment of the crash, so the causes it lists are ranked guesses. Their job is to tell you which file and which line to open first, and what to check when you get there.

What happens to secrets inside the pasted trace?

Obvious secrets are replaced with placeholders before a single line is parsed: bearer tokens, JSON web tokens, basic auth headers, password and API key pairs, connection strings with a password, common cloud and provider keys, private key blocks and email addresses. A note above the reading says what was removed. Pattern matching is not perfect, so read your trace before you paste it. Internal hostnames, customer identifiers and absolute file paths can be sensitive even when no credential is present.

Why is the top frame often not the bug?

The top frame is where the program finally gave up, which is not always where the mistake was made. A null value can be created in one method, handed through several more and only dereferenced at the top of the stack. The frame worth opening is usually the highest one that belongs to your own package, and that is the frame the reading marks.

How is this different from the Incident Log Evidence Analyzer?

The Incident Log Evidence Analyzer takes a stream of logs from an incident and builds a timeline of what happened across services. This tool takes one trace and explains it line by line. Reach for this page when a single error is in front of you and you want to know what it means.