Start a diagnostics UI when a .NET container needs investigation.

Tracebag runs on your Docker host for a debugging session. Search logs, inspect runtime counters, capture stacks and traces, then stop it when the work is done.

Start a debugging session See the demo investigation

Tracebag incident with an ordered capture timeline and its evidence — **A real capture from the included lock-contention demo.**The ordered timeline is on the left; the logs, counter window, Docker state, and diagnostic artifacts are kept beside it.

Start with the question you actually have.

Tracebag is not a replacement for an observability stack. It is a browser interface for one difficult investigation and the evidence needed to explain it.

What changed when the requests started failing?

Search retained container logs and compare the first bad request with Docker health, restart, OOM, and resource events from the same window.

Is the .NET runtime under pressure?

Watch or record CPU, allocation, GC, ThreadPool, contention, and memory counters without attaching an interactive shell to the workload.

What evidence will we need after the incident?

Capture a bounded stack snapshot, EventPipe trace, or dump and keep it with the logs, notes, and exact time range that explain why it was taken.

An endpoint stalls. Requests queue. CPU alone does not explain it.

The demo API can reproduce that exact situation with a bounded lock-contention workload. Tracebag records the counter window, captures stacks and a threading trace, and links the useful findings back to the original evidence.

Nothing in the demo is a mock screenshot or a scripted result. It runs the same images and diagnostic runners used for another opted-in .NET container.

Follow the ten-minute investigation

Tracebag correlation view aligning runtime pressure, trace events, and logs — Runtime pressure, trace events, and logs aligned around the same incident window.

It needs the Docker socket. That is a serious permission.

While Tracebag is running, its backend has Docker administrator capabilities. Use it only on a host you control, access it through localhost or a trusted HTTPS proxy, and stop it after the session.

Read the complete security model

The default boundaries

Containers remain invisible until they carry the opt-in label.
The browser cannot submit shell commands or arbitrary Docker requests.
Diagnostics use fixed profiles, hard limits, and network-isolated runners.
Authentication is enabled and the service binds to localhost.
The supplied stack does not restart automatically.
Evidence stays local unless an operator explicitly exports it.

Try it on an API designed to fail safely.

Generate CPU pressure, allocations, contention, slow requests, downstream failures, or ThreadPool starvation, then investigate the result in Tracebag.

Start with Docker Browse the source