AspNetCore.Diagnostics.HealthChecks: health check packages and a UI for ASP.NET Core
Enterprise HealthChecks for ASP.NET Core Diagnostics Package
At a glance
- What is it?
- The Xabaril repository ships a family of NuGet health check packages for ASP.NET Core plus a separate UI that polls them. Here is what each part does, how to wire up a first check, and where the design runs out of road.
- Who is it for?
- Adopt it if you run ASP.NET Core 8.0, 7.0, 6.0, 5.0, 3.1, 3.0 or 2.2 services and want registered checks for common backing services plus an optional dashboard. Do not adopt it if you need a self-contained agent with no ASP.NET Core host, or if you expect a single package to cover every database and broker you use.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 100 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the Xabaril health check packages actually solve
ASP.NET Core has a health check abstraction built in, and it is deliberately minimal: you register checks and it exposes a status. The awkward part is the long tail of backing services. Every team ends up writing the same probe for SQL Server, Redis, RabbitMQ, Mongo, Elasticsearch, Postgres and a dozen others, each with its own connection handling and timeout behaviour. This repository exists to remove that duplication. It publishes a collection of packages, one per service or platform, each exposing a registration extension you call from your startup code. The README describes the repository as offering "a wide collection of ASP.NET Core Health Check packages for widely used services and platforms", and the package table covers ApplicationStatus, ArangoDB, Amazon S3, Amazon Secrets Manager, Amazon SNS, and many more beyond the excerpt. The audience is .NET teams running services on ASP.NET Core who already accept the built-in health check model and want the probes written for them. It is not a monitoring system, and it is not a replacement for the built-in abstraction. It sits on top of it.
How the packages and the UI fit together
There are two halves, and they are separable. The first half is the check packages. Each one registers an IHealthCheck implementation with the ASP.NET Core health check service through an extension method, so the checks run inside your application process and the result is served from a health endpoint you map. The second half is HealthChecks UI, which is a separate component. It does not run inside your services. It polls configured endpoints on an interval, stores the results, and renders a dashboard with a history timeline. The README's own section list makes that split explicit, with HealthChecks UI, UI Storage Providers, UI Database Migrations, History Timeline, Configuration and Webhooks and Failure Notifications as distinct topics. That separation is the main architectural decision to understand before adopting: your services stay unaware of the dashboard, and the dashboard needs somewhere to persist what it collects. The repository also ships Docker images for the UI and for a Kubernetes operator, and there is a Kubernetes automatic services discovery feature listed alongside the operator.
Getting the packages from NuGet and running a first health endpoint
There is no installer. Distribution is through NuGet, and the README's package table links each package to its own NuGet page, for example AspNetCore.HealthChecks.ApplicationStatus, AspNetCore.HealthChecks.ArangoDb and AspNetCore.HealthChecks.Aws.S3. Pick the package that matches the dependency you want to probe, then register it in the service collection and map the health endpoint. The README does not print a full startup snippet in the excerpt, so the safest first step is the repository's own sample application rather than a snippet reconstructed from memory: samples/HealthChecks.Sample/ sits at the top level of the tree, and samples/HealthChecks.UI.Sample/ and samples/HealthChecks.UIAndApi/ cover the dashboard side. Read the Program.cs in those directories for the exact extension names and the endpoint path the project itself uses. If you also want the dashboard, the UI is a separate application or a container from the xabarilcoding/healthchecksui image, and it is configured with the endpoints it should poll rather than being added to the service you just built. The docker-compose.yml at the repository root shows the backing services the samples expect, including sqlserver on host port 5433, redis, elasticsearch, solr, clickhouse, postgres, eventstore, mongodb, mysql and raven, which tells you how much infrastructure the full sample set assumes.
The UI needs storage, and that is an operational commitment
HealthChecks UI is not a stateless page. It keeps history, and history needs a store. The README lists UI Storage Providers and UI Database Migrations as separate topics, which means you choose a provider and you apply migrations to it. That is a real cost. A team that only wants a green or red light now owns a database schema that has to be migrated when the UI is upgraded, and the repository ships a docker-compose.yml with SQL Server, Postgres, MySQL, MongoDB, RavenDB, Redis, Elasticsearch and others precisely because the storage providers are pluggable and the samples exercise several of them. The payoff is the history timeline, which lets you see when a service started failing rather than only that it is failing now. If you do not need that history, running the UI is a poor trade: you take on a stateful component and its migrations to display information your orchestrator or your existing monitoring already holds.
Where this is the wrong tool
The packages assume your code runs inside an ASP.NET Core host. A background worker, a console job or a service written in another language cannot use them, because the registration model is the ASP.NET Core dependency injection container. The second limitation is coverage. The collection is wide, but it is not exhaustive, and the README presents it as a table of packages rather than a guarantee. If your dependency is not in that table, you write the IHealthCheck yourself and the value of the package drops to whatever the UI gives you. Third, the release cadence deserves a look before you commit. The most recent release listed is release-all-8.0.0-with-valid-apikey from 2024-02-28, and before that release-all-7.0.0 and release-ui-7.0.1 from 2023-07-31. The last push to master was on 2026-06-22, so work is happening in the repository, but the published release line is older than the commit history. Teams that pin to released NuGet versions should check what is actually published rather than assuming the master branch state is available. The README does not document a rollback procedure for the UI's stored data.
How it compares with writing your own checks
The realistic alternative is not another product. It is using the built-in Microsoft.Extensions.Diagnostics.HealthChecks abstractions directly and implementing each probe in your own codebase. The difference in approach is ownership. With the built-in abstractions you control the connection logic, the timeout, the retry behaviour and the exact query sent to each dependency, and you carry the maintenance of all of it. With the Xabaril packages you get the probe written and maintained elsewhere, and you accept its choices about what a healthy dependency looks like. For a single dependency, writing your own is often less work than taking a dependency. For ten, the arithmetic flips. The UI has a similar comparison: the alternative is exposing a health endpoint and letting your existing monitoring scrape it, which avoids the storage provider and the migration burden but gives up the history timeline and the webhooks and failure notifications the UI provides. The README lists webhooks as a UI feature, so that capability lives on the dashboard side, not in the check packages.
Licence and the cost of keeping up
The repository is Apache-2.0, which permits commercial use and modification, and the LICENSE file sits at the repository root. That is a permissive licence and it removes the most common legal objection to adding a dependency. It does not remove the upgrade cost. Each check package depends on the client library for the service it probes, and those client libraries move independently. When your database driver has a major version, the matching health check package has to follow. The repository centralises versioning through Directory.Packages.props, so the packages in the tree move together, but that is an internal detail of the repository and not a promise about what lands on NuGet. Treat the check packages as you would any other dependency with an external client underneath: read the release notes before upgrading, and test the probe against a real instance of the dependency rather than a mock, because the failure mode of a health check is usually a false negative caused by a connection detail.
Editorial conclusion
Adopt it if you run ASP.NET Core 8.0, 7.0, 6.0, 5.0, 3.1, 3.0 or 2.2 services and want registered checks for common backing services plus an optional dashboard. Do not adopt it if you need a self-contained agent with no ASP.NET Core host, or if you expect a single package to cover every database and broker you use. Verify first which of your dependencies has a matching AspNetCore.HealthChecks.* package on NuGet, and check the release history: the newest release listed is release-all-8.0.0-with-valid-apikey from 2024-02-28, while the last push to master was on 2026-06-22, so the code moves ahead of the published packages.
Frequently asked questions
How can I perform health checks in ASP.NET Core with AspNetCore.Diagnostics.HealthChecks?
Register the health check packages you need in the service collection and map a health endpoint in the request pipeline; the repository's samples/HealthChecks.Sample/ directory shows the exact calls. The check packages provide the probes for specific services and platforms, and ASP.NET Core serves the aggregated result from the endpoint you map.
Is ASP.NET Core still supported by AspNetCore.Diagnostics.HealthChecks?
The README lists ASP.NET Core versions 8.0, 7.0, 6.0, 5.0, 3.1, 3.0 and 2.2 as supported, and links separate README files for the NetCore 3.1, 3.0 and 2.2 lines. The repository is not archived and the last push to master was on 2026-06-22.
How can I perform an API health check with AspNetCore.Diagnostics.HealthChecks?
Map a health endpoint in your ASP.NET Core application and register the checks you want against it. If you want a dashboard that polls that endpoint from outside, HealthChecks UI is a separate component configured with the endpoints it should monitor.
How do you configure health checks in .NET Core microservices with AspNetCore.Diagnostics.HealthChecks?
Each microservice registers its own checks and exposes its own health endpoint. The UI side is where the services come together: it polls the configured endpoints, stores the results in a storage provider, and renders the history timeline and webhooks. The repository also lists a Kubernetes operator and automatic services discovery for cluster setups.
What is the alternative to AspNetCore.Diagnostics.HealthChecks?
The direct alternative is using the built-in Microsoft.Extensions.Diagnostics.HealthChecks abstractions and writing each probe yourself, which gives you control over the connection logic and timeouts but leaves you maintaining every check. The Xabaril repository supplies those probes as packages instead.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/xabaril-aspnetcore-diagnostics-healthchecks)