Debug a .NET container after the easy checks stop helping.

Tracebag keeps its logs, runtime counters, Docker state, stack snapshots, and traces in one incident timeline. It runs on your Docker host and stores the evidence there.

Tracebag incident with an ordered capture timeline and its evidence
Swipe to inspectOpen full size
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 another general-purpose dashboard. It is a place to investigate one difficult failure and retain enough evidence to explain it later.

01

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.

02

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.

03

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
Swipe to inspectOpen full size
Runtime pressure, trace events, and logs aligned around the same incident window.

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

Tracebag uses Docker access to inspect opted-in workloads and launch temporary diagnostic runners. It should run only on a host you control, bound to localhost or protected by a trusted HTTPS proxy.

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.
  • 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.