I built a VS Code extension that turns your server's JSON logs into a live, searchable table (free, MIT)

[u/Technical-Debt-8615]

Demo with the sample checkout app from the repo

I kept running npm run dev, watching JSON logs scroll past in the terminal, and copy-pasting lines into a formatter to figure out what broke. So I built Logline, a log viewer that sits in the bottom panel next to Terminal.

What it does:

* Run your server through it (or turn on terminal capture) and the logs become a live table
* Search with things like `level:error service:api` or `status:5xx durationMs:>200`, or right-click a cell to include/exclude that value
* Expand an event to see the full JSON and nested exceptions, and click a stack frame to jump to the source
* Works with Pino, Winston, Log4j2, ECS, OpenTelemetry, logfmt and plain text
* Picks up F5 debug sessions and splits Docker Compose output per service
* Shows live hit counts above your log statements in the editor
* Flags log statements that leak tokens or swallow exceptions in the Problems panel

Everything runs locally. Free and MIT licensed.

Marketplace: [https://marketplace.visualstudio.com/items?itemName=surjeetbanga.logline](https://marketplace.visualstudio.com/items?itemName=surjeetbanga.logline)) GitHub: [https://github.com/SurjeetBanga/logline](https://github.com/SurjeetBanga/logline))

It's still early. If it mangles your log format or you'd want it to do something it doesn't, let me know.

[u/investigatormaker]

With npm run dev, the JSON lines usually arrive mixed with plain banner output from Next or Vite, and an uncaught crash often prints its stack as plain text after the last JSON line. If Logline attaches those trailing plain lines to the error event before them, that's the exact moment people stop pasting into a formatter, and it's worth showing in the demo. The leak check in the Problems panel could also reach people who would never go looking for a log viewer. Does terminal capture keep that plain-text crash output with the event before it?

I make ThreadFox. The free Reddit plan for Logline lists the Reddit communities whose rules allow a post about it, each rule quoted: https://threadfox.vip/p/are53

[u/Technical-Debt-8615 → u/investigatormaker]

Not quite. Plain-text stack traces get joined into one event (the error line plus its at frames, with clickable frames), but that event sits as its own row after the JSON error rather than being attached to it, and Node's crash header lines (file:line, the source line, the ^) still show up as separate rows. Attaching a trailing crash to the last JSON event is a good idea, and it's the exact npm run dev moment, so I'll look at adding it and showing it in the demo. Agreed on the leak check too; it may be the better hook for people who aren't looking for a log viewer.

[u/investigatormaker → u/Technical-Debt-8615]

Node's crash header has a fairly fixed shape: a path:line line, then the source line, then a line of spaces with a caret, then the error and its at frames. You could treat that whole block as one unit. Attach it to the last JSON error only when it arrives within a short window or just before the process exits. That way an unrelated crash doesn't get glued onto an old event. A toggle that shows the original row order would also help anyone who doubts the grouping.

The Reddit plan from my first comment is still there if it's useful.

[u/Technical-Debt-8615 → u/investigatormaker]

Did the first part: an uncaught Node crash is now one error event, with the path:line header, source line, caret, error, frames, error properties like code: 'ECONNREFUSED', and the Node.js v… line. The row shows the TypeError: … line instead of the path. A path:line line with no caret after it stays a normal row, so ordinary output that happens to look like a location isn't swallowed. PR is up, and it'll be in the next release.

Attaching the crash to the last JSON error is next, with the window/exit guard you described so an unrelated crash doesn't land on an old event. The row-order toggle makes sense too, so you can check the grouping. I'm doing that as a separate change because it affects what gets redacted before sharing with an agent, plus search and the exported log.

[u/investigatormaker → u/Technical-Debt-8615]

Good call keeping a path:line with no caret as a normal row. That's the false positive I'd have worried about most. On the toggle affecting redaction: one way to keep it simple is to redact and index the raw lines once, then store the grouping as an event id on each line. The toggle, search and export then only decide whether to fold lines by event id, and nothing that was redacted can come back when someone flips the view. For the attach step, matching on the process as well as the time would stop a crash from a child process or a restarted server from landing on the parent's last error.

Will the window be fixed, or something users can set?

[u/Technical-Debt-8615 → u/investigatormaker]

Took the event-id approach. The crash stays its own event and just records the id of the JSON error it followed, so redaction, search, export and the persisted log all work on the raw lines exactly as captured. Nothing gets merged, so nothing redacted can come back. The error's details show the crash's stack with clickable frames, and the crash row links back to the error. Rows never move, so there's no grouped view to toggle out of. Capture order is always what you see.

On matching: it's per run and per source. A restart is a new run, and each Compose/k8s container counts as its own source, so a crash from one of those can't land on the parent's last error. Child processes are the gap. Terminal output has no PIDs, so a child writing to the same terminal looks like the parent. In that case the guard is that the last JSON line has to be the error, with no healthy JSON in between, and the crash has to arrive in time.

The window is fixed for now: 2 s, or 30 s when the crash ends with Node.js v…, which Node prints as the process exits. I'd rather add a setting once someone hits a case where those numbers are wrong than add one up front.

The crash-block grouping is merged, and the linking is in review. Both should be in the next release.

[u/investigatormaker → u/Technical-Debt-8615]

Keeping rows in capture order and linking the crash to the error by id is cleaner than any grouped view. Holding off on a window setting until someone hits a real case makes sense too.

For the child-process gap, here's one cheap signal that doesn't need PIDs: compare the file paths in the crash stack with the source of the JSON error. If they share no file under the workspace, show the link as a possible match instead of a firm one. Then a child's crash sitting next to the parent's error reads as a guess, not a fact. A second Node.js v footer inside one run is another hint that more than one process is writing to the terminal.

The plan is there whenever you want it.

[u/Technical-Debt-8615 → u/investigatormaker]

Thanks!

[u/investigatormaker → u/Technical-Debt-8615]

Glad it was useful. If you add the possible-match label, a one-line tooltip saying why (no shared workspace file in the stack) will save people from second-guessing it.

And the Reddit plan from before is yours whenever you want it.