tool / observability

Log Viewer

Parse plain logs, filter by level/keyword, and generate quick counts for incident triage.

Back to tools index

What It Does

Splits raw log input line-by-line, detects severity levels (INFO, WARN, ERROR, DEBUG, TRACE), and filters by level and keyword — producing a live summary count and matched log view.

Why It Matters

Fast log triage without a full observability stack. Useful for local runs, paste-in logs from CI, or quick incident scans during on-call.

How To Use

  • Paste raw log lines into the input.
  • Select a level filter or leave ALL to scan everything.
  • Add a keyword to narrow results (e.g. timeout, db).
  • Click Analyze logs to see summary and matched lines.

Where It Fits

Not every log question deserves a Datadog query. You've got a chunk of output from kubectl logs, a failed CI job, or a docker logs dump, and all you want to know is how many errors are in there and what they say. Paste, filter by ERROR, done. It's the middle ground between scrolling a terminal buffer by hand and waiting for logs to land in your observability platform — which they never will if the output came from a laptop or a one-off script.

How Level Detection Works

Each line is scanned for a severity token — INFO, WARN, ERROR, DEBUG, or TRACE, case-insensitive — anywhere in the line. That means it doesn't care about your timestamp format or field order; plain text, logfmt, and JSON lines all work as long as the level appears somewhere in the text. Lines with no recognizable level get counted as UNKNOWN instead of being dropped, so the summary totals always add up to what you pasted.

Frequently Asked Questions

Are my logs uploaded anywhere?

No. Parsing, counting, and filtering all happen in your browser. That matters with logs, because they love to contain things they shouldn't — user emails, tokens, internal hostnames.

Can I combine the level and text filters?

Yes, they stack. Pick ERROR and type timeout to see only error lines mentioning timeouts. The text filter is case-insensitive and matches anywhere in the line.

Why are all my lines UNKNOWN?

Your logs probably don't spell out a level word — some formats use single letters (E, W) or numeric severities. The keyword filter still works fine; only the per-level counts need a recognizable token.

Does it handle multi-line entries like stack traces?

Each line is treated independently, so a stack trace shows up as one ERROR line followed by UNKNOWN continuation lines. To read the full trace, keep the level filter on ALL and use a keyword instead.

// huntermussel

Drowning in production logs?

HunterMussel deploys centralized observability stacks with structured logging, distributed tracing, and AI-assisted anomaly detection — so you catch issues before users do.

Explore Cloud Infrastructure & AI →

Advertisement · Publicidade