Use case · SRE, DevOps & Security

The logs are on fire. Tab-switching isn't helping.

npx duckviz ./logs/ -r. Correlate every log file in the folder with full DuckDB SQL, in a browser tab, in seconds. No ingestion pipeline. No Elastic cluster. No Kibana tax.

Launch in browser CLI reference

Back to home

Debugging from `grep | awk | sort | uniq -c` is a rite of passage. It's also a waste of a Tuesday.

Three log files, three formats, one incident. Standing up an ELK stack just to correlate them takes longer than the incident itself. DuckViz skips the ingestion step entirely — the parser runs in a WASM worker, DuckDB runs in-tab, and you query everything as SQL tables.

Pager duty, the usual way

SSH to three boxes. tail -f three files
Copy suspect lines into a Slack thread
Regex-wrangle them into shape with awk
Realise you needed a time join; start over in Python
Write the post-mortem at midnight from memory

Pager duty with DuckViz

npx duckviz ./logs/ -r
AI detects every log format automatically
Each file becomes a DuckDB table; join across them
Query with CTEs, window functions, time buckets
Export a timeline chart straight into the RCA

The CLI, in full

One command. Zero install. The CLI spins up a local bridge, pushes your files into the browser app via a bearer-token channel, and opens the analysis view.

terminal

# Analyse a single file
npx duckviz ./access.log

# Recursively load a whole directory of logs
npx duckviz ./logs/ -r

# Fresh session, wiping any prior data
npx duckviz data.csv --fresh

# Pipe from another command
kubectl logs my-pod --since=1h | npx duckviz -

What actually makes it fast

AI log-format detection — Sysmon, Windows Event XML, NGINX / Apache access logs, syslog, JSON, delimited — sampled once, parsed forever.
WASM parser — Rust-built, streams records into DuckDB in batches of 5,000 without blocking the UI.
Full DuckDB SQL — window functions, CTEs, time buckets (time_bucket), regexp_extract, JSON extraction. Everything you need to correlate events.
Security-hardened bridge — bearer-token auth, DNS-rebinding guard, path-traversal protection, URL scrubbing, manifest-gated wipes. The CLI doesn't open a hole in your workstation.
Local-only — files are pushed from the CLI to a tab on your own machine. Nothing egresses to any cloud.

Worked example: finding the bad deploy

DuckDB SQL — in browser

-- 5xx error rate per minute, windowed over 24h
WITH per_min AS (
  SELECT
    time_bucket(INTERVAL 1 MINUTE, ts) AS minute,
    COUNT(*) FILTER (WHERE status >= 500)::DOUBLE
      / COUNT(*) AS err_rate
  FROM t_access_log
  WHERE ts >= now() - INTERVAL 24 HOUR
  GROUP BY 1
)
SELECT
  minute,
  err_rate,
  avg(err_rate) OVER (
    ORDER BY minute
    ROWS BETWEEN 10 PRECEDING AND CURRENT ROW
  ) AS smoothed
FROM per_min
ORDER BY minute;

The chart goes straight into the post-mortem doc, PDF-exported in one click.

Frequently asked

Does the CLI upload my logs anywhere?

No. The CLI opens a local bridge bound to 127.0.0.1, authenticated with a bearer token, and hands the files to a browser tab on the same machine. Nothing egresses.

Can I use it for incident response on production data?

That's exactly what it's built for. No cloud, no vendor review, no signed BAA required — just a CLI and a tab.

What log formats are supported?

Sysmon XML, Windows Event XML, JSON logs, NGINX / Apache access logs, syslog, CSV/TSV-style delimited logs, and any format AI can detect from a 10-line sample. Unknown formats can be parsed with a regex you supply.

Can I integrate this into CI or a runbook?

Yes. Pipe output into npx duckviz -, or use the Node SDK to headlessly generate dashboards and PDF reports during incident response.

Next time the pager fires, skip the pipeline.

npx duckviz ./logs/ -r. A browser tab. Full SQL. Answers before the next page.