dotnet-monitor attaches to a running .NET app and collects the artifacts you need

Two mechanisms: an API for now, rules for always

Running a .NET application in diverse environments makes collecting diagnostic artifacts such as logs, traces and process dumps hard, and dotnet-monitor exists to give one way to collect them regardless of where the application runs. The design splits into two mechanisms, and the split maps onto two very different situations. The HTTP API is for on demand collection: you call the endpoints when you already know the application is in trouble and want more information about it. Triggers are the rule based configuration for always on collection, where you configure rules so that artifacts are gathered when a condition is met, and the example the documentation gives is collecting a process dump when you have sustained high CPU. The first is a tool you reach for during an incident. The second is a standing policy that captures evidence before anyone notices there is a problem.

The HTTP API is the part you will use first

The API documentation lives in the repository at documentation/api/README.md, and the endpoints exist for the case where an operator knows something is wrong right now. That framing is the useful part of the design. Because the tool talks to a live process over HTTP, the diagnosis loop does not require a rebuild, a redeploy or a debugger attached to a production machine. The README is careful to link out rather than to explain, so the concrete details you need, the available endpoints and their request shapes, are in that API document rather than in the repository front page. A second set of documents covers the rule based side at documentation/collectionrules/collectionrules.md. The rest of the documentation directory holds the install and configuration guide, the release history at documentation/releases.md, and walkthroughs in videos-and-tutorials.md.

An HTTP surface on a production process is a security decision

The tool is explicitly a diagnostic endpoint attached to a running application, and the repository treats that as a security matter rather than a footnote. Security issues and bugs are reported privately by email to the Microsoft Security Response Center at [email protected], with a stated expectation of a response within 24 hours and a request to follow up if that does not arrive. The project also points at the Microsoft .NET Core and ASP.NET Core Bug Bounty Program, which tells you that vulnerabilities in this area are treated as in scope for paid reporting. The repository also carries a SECURITY.md of its own. What the README does not do is tell you how the endpoints are authenticated, so anyone deploying this needs to read the API documentation and the configuration guide before exposing a port, rather than assuming the defaults are safe for a public network.

Three release lines, patched in parallel

The release history shows three supported branches at once. v10.0.5 was published on 2026-10-13, v9.0.6 on 2026-09-09 and v8.1.4 on 2026-09-09, and the two older lines received patches within an hour of each other. That is the shape of a tool that ships inside the .NET servicing story rather than as a standalone app: major versions correspond to .NET release lines, and each line keeps getting fixes. The upgrade cost for an adopter is therefore a version choice rather than an upgrade treadmill, and the repository's own release history document is the place to check which lines are current. The repository is not archived and the last push was on 2026-10-19, days after the newest tag, so the code moves faster than the release notes pages might suggest.

The solution is large, and the samples show where it is meant to run

The top level of the repository is that of a substantial .NET product. There is dotnet-monitor.sln, a src directory, a documentation directory, an eng directory for the engineering scripts, and a samples directory whose contents say a lot about the intended deployment: samples/AKS_Tutorial, samples/Docker, samples/Grafana, samples/K8s_Ephemeral_Containers and samples/Kubernetes. The build is scripted for both platforms, with build.sh, restore.sh and test.sh next to Build.cmd, Restore.cmd and Test.cmd, and a set of start scripts for Visual Studio and VS Code. The toolchain is pinned by global.json, package versions are centralised in Directory.Packages.props with a Directory.Build.props for shared properties, and NuGet.config handles feed configuration. There is a CMakeLists.txt and a CMakeSettings.json, which points to native components in the tree, and a .devcontainer directory for a containerised development environment.

Attaching from outside is different from instrumenting from within

The alternative to dotnet-monitor is to build collection into your own application. That means your code, or a library you reference, produces the traces and dumps and ships them somewhere, either on a timer or in response to a signal of your own. The difference in approach is where the responsibility sits. With dotnet-monitor the application is untouched, and you gain the ability to pull artifacts from a build you did not modify, which is the deciding factor for a fleet of services you do not own or cannot rebuild. The cost is that the tool attaches to a live process and exposes an HTTP interface, so your diagnostics now depend on deploying and securing a second component next to every application. If you can change the application, instrumenting it avoids that second component and lets you capture exactly the state you care about. If you cannot, the external collector is the only option that stays practical.

MIT licensed, foundation hosted, and documented elsewhere

dotnet-monitor is licensed under the MIT licence, with the text in LICENSE.TXT at the repository root, and it is a .NET Foundation project, which is the governance structure the community .NET projects use. The project has adopted the Contributor Covenant code of conduct, points at the .NET Foundation discussions for general open source conversation, and maintains its own contributing guide and a code of conduct document. There is also a public survey for anonymous feedback on using the tool. A blog post announcing dotnet-monitor dates it to .NET 6, which is useful context for judging the age of the design. The practical point for anyone reading the repository is that the README is an index, not a manual: the install steps, the configuration surface and the endpoint list are all in the documentation directory, and the build instructions for working on the tool itself are at documentation/building.md.

Editorial conclusion

Adopt dotnet-monitor when you operate .NET applications in environments where pulling a log bundle or a process dump by hand is impractical, since the HTTP API and the collection rules cover both the emergency case and the always on case, and the samples show how it fits AKS, Docker and Kubernetes. Do not adopt it if your diagnostics are already covered by instrumentation inside the application, since attaching an external collector gives you artifacts without code changes but also puts a reachable endpoint on a process you care about. Before you deploy it, read the API documentation for how the endpoints are secured, pick the release line that matches the .NET version your application targets, and confirm the rules you enable will not fill the disk of the host you deploy to.

Frequently asked questions

Official sources

1. dotnet/dotnet-monitor on GitHub
2. Issues
3. License: MIT
4. README
5. Releases