{{ summaryHeading }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ recurringLabel }} {{ traceCountLabel }} {{ runtimeResolutionLabel }}
Separate trace samples with blank lines. Raw source is not added to the share URL.
{{ sourceError }}
{{ fileStatus || 'Drop one LOG or TXT file onto the textarea.' }}
Auto chooses a runtime when only one family is recognized, otherwise Mixed. Pin a runtime for ambiguous wrapper logs.
frames
Kept local because paths and namespaces may reveal internal project structure.
Reduce volatile values to group recurring failures; disable it to retain message detail.
{{ normalize_tokens ? 'IDs, timestamps, hashes, and long numbers are reduced' : 'Raw message tokens are preserved' }}
Prefer application frames; disable it to include dependency frames in the signature chain.
{{ skip_library_frames ? 'Prefer owned or non-library frames' : 'Keep library frames in normal order' }}
The default shows the eight most frequent groups without changing full-sample counts.
groups
The shipped defaults cover common Node, Python, JVM, .NET, Go, PHP, and Ruby library locations.
RankFingerprintTracesSignatureTop frameCopy
{{ row.rank }}{{ row.fingerprint }}{{ row.count }} ({{ row.share_label }}){{ row.signature }}{{ row.top_frame }}
FingerprintIncluded framesSkipped framesExample headerCopy
{{ row.fingerprint }}{{ row.included_frames }}{{ row.skipped_frames }}{{ row.example_header }}
PrioritySignalEvidenceNext actionCopy
{{ row.priority }}{{ row.signal }}{{ row.evidence }}{{ row.next_action }}
{{ chartError }}
Application Log Pattern Analyzer Group application logs into stable fingerprints, compare severity and time clusters, and triage recurring patterns without uploading the source.
Web Server Detector Detect visible server and application clues at a public URL, including CDN or proxy evidence across redirects and a clear confidence score.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.
SARIF Security Findings Analyzer Analyze SARIF logs into a local release gate with prioritized findings plus hotspot and tracking-coverage checks for security review.

Incident queues become noisy when the same defect produces traces with different line numbers, request values, timestamps, or generated identifiers. Exact-text matching splits those occurrences apart. Aggressive deduplication creates the opposite problem by merging failures that only look similar.

A stack trace combines an exception or panic with a sequence of call frames. The exception type names the broad failure, the message often contains instance-specific detail, and the frames show the path through application, framework, and runtime code. For routing, the first frame owned by the application is often more useful than the first printed frame.

A signature keeps selected stable evidence and turns it into a repeatable fingerprint. A top-frame policy tolerates line movement and wrapper noise. A frame-chain policy distinguishes different call paths. A message-inclusive policy keeps normalized message meaning when one exception type represents several defects.

Normalization can replace quoted values, universally unique identifiers, timestamps, long hexadecimal strings, and multi-digit numbers. That reduces accidental splits, but it can also erase a value that separates two real causes. The fingerprint must therefore remain attached to representative frames and an example header.

Trace boundaries matter before any signature logic runs. Blank lines separate the trace blocks in a pasted sample. Logs that split one multiline exception into many records or merge unrelated exceptions will produce misleading counts. Fingerprints support recurrence analysis and ownership routing; they do not prove severity or root cause.

How to Use This Tool:

Collect complete traces from one incident window and choose how much message and frame detail should define a group.

  1. Paste or load the traces. Separate complete traces with at least one blank line. LOG and TXT input is limited to 500,000 characters.
  2. Choose Runtime. Auto detection recognizes common JavaScript, Python, Java, .NET, Go, PHP, and Ruby shapes and resolves mixed evidence as Mixed runtimes. Pin a runtime when the wrong frame grammar is selected.
  3. Select Signature mode. Start with Exception + top application frame. Use a frame chain when call-path differences matter, or include the message when normalized message templates separate meaningful failure classes.
  4. Set Application frame hints. Add stable path or namespace fragments for code your team owns. The first matching frame takes priority over automatic library skipping.
  5. Adjust normalization and library patterns. Inspect included and skipped frames after changing either option. Frame depth accepts 1 to 8; visible signatures accepts 1 to 25.
  6. Compare frequency with evidence. Confirm the exception template, chosen frames, deploy timing, and ownership before merging incidents under one fingerprint.

Interpreting Results:

Recurring failures found means at least one fingerprint contains more than one trace. Baseline signatures ready means every fingerprint occurs once in the current input. Neither status reflects business impact.

Top share is the leading group's trace count divided by all parsed traces. Read the percentage with the count: 100% of two traces is much weaker recurrence evidence than 100% of two thousand.

  • When unrelated messages merge, use the message-inclusive mode or reduce normalization.
  • When one failure splits into many groups, improve application hints, remove stable library wrappers, or shorten the frame chain.
  • Keep singleton groups when their severity or ownership still warrants investigation.
  • Compare fingerprints only when runtime, mode, normalization, frame depth, and frame patterns match.

Technical Details:

Signature generation is a deterministic transformation from trace blocks to parsed frames, normalized evidence, a signature string, and a compact hash. Every upstream choice can change group membership, so the visible frame evidence is necessary for auditing the result.

Transformation Core:

Stage Mechanism Grouping consequence
Split One or more blank lines create trace blocks. A wrong boundary changes the trace count before parsing.
Parse Runtime-specific patterns extract exception candidates, functions, file paths, and line evidence. Unrecognized lines do not enter the frame chain.
Select The first application-hint match wins; otherwise the first non-library frame or first parsed frame is preferred. Hints and library patterns can change the chosen ownership frame.
Normalize Short quoted values, UUIDs, dates and timestamps, long hexadecimal tokens, and numeric runs are replaced when enabled. Paths keep at most three trailing segments. Volatile instances can join while function and shortened path remain stable.
Assemble Exception type is combined with a preferred frame, a frame chain, or a normalized message plus preferred frame. Mode sets the grouping sensitivity.
Fingerprint A deterministic 32-bit FNV-1a-style hash becomes sig-xxxxxxxx. The key is reproducible but not cryptographically collision-resistant.

Mechanism Core:

Top-frame mode hashes the normalized exception type and one preferred frame identity. Frame-chain mode uses up to the chosen number of eligible frames. Strict-message mode adds the normalized message to the exception type and preferred frame. Frame identity uses the shortened path and normalized function name; line and column numbers remain evidence but do not enter the key.

The visible-signature limit only truncates ranking, frame-evidence, and frequency output. It does not change total traces, total signatures, recurrence count, or the leading share. Groups sort by descending trace count and then fingerprint.

Formula Core:

Every frequency percentage uses the complete parsed trace set, including groups hidden by the visible limit.

Sgroup= NgroupNtraces×100

Canonical percentages are rounded to six decimal places and displayed to one decimal place. A recurring fingerprint has a count greater than 1.

Privacy and Accuracy Notes:

Trace text and loaded files stay in the browser during analysis. Traces can contain file paths, hostnames, identifiers, tokens, SQL fragments, request data, and personal information. Token normalization is a grouping aid rather than a complete redaction method.

  • Runtime detection relies on recognizable text patterns and may classify unfamiliar or combined formats as mixed.
  • Source maps, native symbols, inlining, asynchronous causal chains, and wrapper context are not resolved.
  • Hash collisions and normalization collisions are possible; keep representative evidence with each fingerprint.

Worked Examples:

Line movement without a new failure group

Two JavaScript TypeError traces reach the same buildInvoice function through the same application path, but one reports line 42 and the other line 87. Top-frame mode produces the same frame identity because line numbers stay outside the key. The normalized evidence template also replaces a changing quoted invoice value or long number, although top-frame mode does not include the message in its key.

References: