OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
≋

Validator Log Analyzer

Find failure patterns in node logs
InputUp to 2 MB / 20 000 lines — larger inputs are truncated.
Result1 findings
GoodNo known validator failure pattern detected.Unknown1× · L1–1High

IPs, hostnames, paths and tokens are masked in snippets.

Introduction

The Validator Log Analyzer scans pasted node or validator logs and reports known failure patterns: out-of-memory events, full disks, missed slots and attestations, duplicate validator keys, slashing risk, clock drift, low peer counts, timeouts, connection failures, database corruption, incompatible snapshots and repeated restarts.

Every detection shows severity, category, occurrence count, first and last occurrence line, a masked snippet, the likely cause, recommended checks and a confidence level. The analysis runs entirely in the browser: logs are neither uploaded nor persisted.

Objective

  • Detect the failure patterns that most often take down or penalise a validator node.
  • Group occurrences by pattern with count, first and last line, and a masked snippet.
  • Separate shared Linux rules from chain-specific consensus rules.
  • Mask IPv4/IPv6 addresses, hostnames, paths, tokens and possible secrets, and never echo seed/private-key material in full.

Inputs

  • A paste of journald, syslog, node or validator output, or a .log/.txt file.
  • Input is capped at 2 MB and 20 000 lines; larger inputs are truncated with a notice.
  • Nothing is uploaded; the data can be cleared with one click.

How it works

Each line is matched against a set of shared Linux patterns (OOM, disk full, I/O errors, clock drift, auth failures, refused connections, timeouts, port conflicts, database corruption, restart loops) and validator/consensus patterns (missed slots, missed attestations, vote failures, duplicate validator keys, slashing indicators, snapshot and version mismatches).

Occurrences are counted per pattern with first and last line numbers; a short snippet of the first occurrence is kept and masked.

Lines that look like seed phrases or private keys are never repeated: they produce a redacted high-severity finding.

Repeated start markers produce a restart-loop finding; recurring error lines that match no known pattern produce an unknown-error finding.

Detections are ordered by severity and rendered with cause, recommended checks and confidence.

Testable example

Try it — the analysis runs locally in your browser.

Example

Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (geth)
Aug 22 14:07:02 node1 geth[8492]: ERROR[08-22|14:07:02] Failed to write block   err="no space left on device"
Aug 22 14:08:40 node1 geth[8492]: WARN[08-22|14:08:40] Missed slot            slot=512344

Expected output

HIGH  OOM killer        · 1 occurrence · line 1
HIGH  Disk full         · 1 occurrence · line 2
WARN  Missed slot       · 1 occurrence · line 3
Likely cause: memory pressure + full disk → node stalled and missed a slot.

Reading the output

  • High findings (OOM, disk full, database corruption, slashing risk, duplicate validator) need action before the node can be trusted again.
  • A missed slot or attestation is a warning: one is noise, a pattern is a problem.
  • The masked snippet preserves context for searching while protecting IPs, paths and tokens.
  • A clean result means no known pattern matched — it is not proof the node is healthy.

Risks

  • An OOM-killed node mid-sync can corrupt its database and force a re-sync.
  • Duplicate validator keys and slashing indicators are the most dangerous findings: act immediately and stop the affected process.
  • Logs can contain secrets. The tool masks them, but do not paste logs containing real keys anywhere.

Limitations

  • Pattern matching is heuristic; false positives and misses are possible.
  • It analyses the pasted window only — it cannot see events before or after it.
  • It is a triage aid, not a monitoring system.

Official references

FAQ

Where does my log data go?

Nowhere. The analysis runs locally in your browser. There is no upload endpoint, the data is not persisted, and the URL never contains log content. Use the clear button to wipe the textarea.

What should I do if it finds a slashing indicator?

Stop the validator process immediately, do not restart it with the same keys until you understand the cause, and check the chain's slashing documentation. This tool only detects patterns; the decision is yours.

Why are IPs and paths replaced with <ip>/<path>?

Logs are sensitive. Masking lets you search and share snippets without leaking your infrastructure details or any credentials that may appear in log lines.