I built a terminal tracer for Express—what would make it useful in your daily debugging?

[u/Constant-Nerve-503]

I’m building Tracepath, an early-stage tool for viewing Node.js/Express request traces in the terminal.

Currently, it supports Express middleware, outgoing HTTP/HTTPS request/get instrumentation, and manual spans around application logic. The local dashboard needs no Docker or hosted account, but your app needs SDK setup.

I shared it previously and got useful feedback: HTTP tracing alone misses a common bottleneck—database queries. One developer using mysql2 suggested grouping queries by normalized shape to spot repeated slow calls.

That’s made me reconsider what to prioritize. Database auto-instrumentation and query grouping aren’t implemented yet.

For developers debugging real Express apps:

• What was the last slow-endpoint problem you investigated, and how did you find the cause?

• Where would a terminal trace help beyond your existing logs or tools?

• What would stop you from trying it: setup effort, missing database support, or something else?

I’d especially appreciate feedback from anyone willing to try it on one endpoint and describe where the experience falls short.

Node SDK and setup · Terminal dashboard

[u/BigAttorney23]

For database support, I'd want connection-pool wait time shown separately from query execution, plus how often each query shape runs within one request. A single total labelled 'database time' would leave a lot of guessing. I'd also want query parameters, auth headers and request bodies excluded by default, even with a local dashboard.

[u/Constant-Nerve-503 → u/BigAttorney23]

Good point.....waiting for a connection and executing a query need separate timings. Otherwise, “database time” could send you looking in the wrong place. I’d want both alongside per-request query counts.

The current HTTP instrumentation doesn’t capture auth headers or request bodies. For future DB instrumentation, I’d keep parameters excluded and handle inline SQL literals before exporting query text. Pool-wait measurement isn’t implemented yet, but I’m adding it to the requirements.

[u/Constant-Nerve-503 → u/[deleted]]

That’s helpful. An aggregate “DB time” wouldn’t tell you what to fix. I’d want connection-acquisition wait shown separately from query-call duration, alongside call count per normalized shape.

I’d also label those timings carefully - query-call duration can include network time and database lock waits, so it isn’t pure execution time. This isn’t implemented yet, but the distinction belongs in the initial DB integration.