DotNetDiag HealthChecks

DotNetDiag HealthChecks is the actively maintained fork of AspNetCore.Diagnostics.HealthChecks. This repository offers a wide collection of ASP.NET Core health check packages for widely used services and platforms.

ASP.NET Core versions supported: 10.0,,8.0 and netstandard2.0 !

Sections

HealthChecks UI

UI
UI Storage Providers
UI Database Migrations
History Timeline
Configuration
Webhooks and Failure Notifications
HttpClient and HttpMessageHandler Configuration

HealthChecks UI and Kubernetes

Kubernetes Operator
Kubernetes automatic services discovery

HealthChecks and Devops

Releases Gates for Azure DevOps Pipelines

HealthChecks Tutorials

Tutorials, Demos and walkthroughs

Docker images

HealthChecks repo provides following images:

The current published container images still use the xabarilcoding/* namespace. Package IDs, repository links, and documentation branding have moved to DotNetDiag.

Image	Downloads	Latest	Issues
UI
K8s operator

Health Checks

HealthChecks packages include health checks for:

NuGet package IDs follow the convention: DotNetDiag.<project name>.

Package	Downloads	NuGet Latest	Issues	Notes
ApplicationStatus
ArangoDB
Amazon S3
Amazon Secrets Manager
Amazon SNS
Amazon SQS
Amazon Systems Manager
Azure Application Insights
Azure Tables
Azure IoT Hub
Azure Key Vault Secrets
Azure Event Hubs
Azure Blob Storage
Azure File Storage
Azure Queue Storage
Azure DigitalTwin				Subscription status, models and instances
Azure Key Vault
Azure Search
Azure Service Bus				Queue and Topics
ClickHouse
Consul
CosmosDb				CosmosDb and Azure Table
Dapr
Amazon DynamoDb
Elasticsearch
EventStore				TCP EventStore
EventStore gRPC				gRPC EventStore
Google Cloud Firestore
Gremlin
Hangfire
IbmMQ
InfluxDB
Kafka
Kubernetes
Milvus				Preview-only because `Milvus.Client` is prerelease-only
MongoDB
MySql
Nats				NATS, messaging, message-bus, pubsub
Network				Ftp, SFtp, Dns, Tcp port, Smtp, Imap, Ssl
Postgres
OpenID Connect Server
Oracle
Qdrant
RabbitMQ
RavenDB
Redis
SendGrid
SignalR
Solr
Sqlite
Sql Server
SurrealDB
System				Disk Storage, Folder, File, Private Memory, Virtual Memory, Process, Windows Service
Uris				Single uri and uri groups

We support netcoreapp 2.2, 3.0 and 3.1. Please use package versions 2.2.X, 3.0.X and 3.1.X to target different versions.

Install-Package DotNetDiag.HealthChecks.ApplicationStatus
Install-Package DotNetDiag.HealthChecks.ArangoDb
Install-Package DotNetDiag.HealthChecks.Aws.S3
Install-Package DotNetDiag.HealthChecks.Aws.SecretsManager
Install-Package DotNetDiag.HealthChecks.Aws.Sns
Install-Package DotNetDiag.HealthChecks.Aws.Sqs
Install-Package DotNetDiag.HealthChecks.Aws.SystemsManager
Install-Package DotNetDiag.HealthChecks.Azure.Data.Tables
Install-Package DotNetDiag.HealthChecks.Azure.IoTHub
Install-Package DotNetDiag.HealthChecks.Azure.KeyVault.Secrets
Install-Package DotNetDiag.HealthChecks.Azure.Messaging.EventHubs
Install-Package DotNetDiag.HealthChecks.Azure.Storage.Blobs
Install-Package DotNetDiag.HealthChecks.Azure.Storage.Files.Shares
Install-Package DotNetDiag.HealthChecks.Azure.Storage.Queues
Install-Package DotNetDiag.HealthChecks.AzureApplicationInsights
Install-Package DotNetDiag.HealthChecks.AzureDigitalTwin
Install-Package DotNetDiag.HealthChecks.AzureKeyVault
Install-Package DotNetDiag.HealthChecks.AzureSearch
Install-Package DotNetDiag.HealthChecks.AzureServiceBus
Install-Package DotNetDiag.HealthChecks.ClickHouse
Install-Package DotNetDiag.HealthChecks.Consul
Install-Package DotNetDiag.HealthChecks.CosmosDb
Install-Package DotNetDiag.HealthChecks.Dapr
Install-Package DotNetDiag.HealthChecks.DynamoDb
Install-Package DotNetDiag.HealthChecks.Elasticsearch
Install-Package DotNetDiag.HealthChecks.EventStore
Install-Package DotNetDiag.HealthChecks.EventStore.gRPC
Install-Package DotNetDiag.HealthChecks.Gcp.CloudFirestore
Install-Package DotNetDiag.HealthChecks.Gremlin
Install-Package DotNetDiag.HealthChecks.Hangfire
Install-Package DotNetDiag.HealthChecks.IbmMQ
Install-Package DotNetDiag.HealthChecks.InfluxDB
Install-Package DotNetDiag.HealthChecks.Kafka
Install-Package DotNetDiag.HealthChecks.Kubernetes
Install-Package DotNetDiag.HealthChecks.Milvus -Prerelease
Install-Package DotNetDiag.HealthChecks.MongoDb
Install-Package DotNetDiag.HealthChecks.MySql
Install-Package DotNetDiag.HealthChecks.Nats
Install-Package DotNetDiag.HealthChecks.Network
Install-Package DotNetDiag.HealthChecks.NpgSql
Install-Package DotNetDiag.HealthChecks.OpenIdConnectServer
Install-Package DotNetDiag.HealthChecks.Oracle
Install-Package DotNetDiag.HealthChecks.Qdrant
Install-Package DotNetDiag.HealthChecks.Rabbitmq
Install-Package DotNetDiag.HealthChecks.RavenDB
Install-Package DotNetDiag.HealthChecks.Redis
Install-Package DotNetDiag.HealthChecks.SendGrid
Install-Package DotNetDiag.HealthChecks.SignalR
Install-Package DotNetDiag.HealthChecks.Solr
Install-Package DotNetDiag.HealthChecks.Sqlite
Install-Package DotNetDiag.HealthChecks.SqlServer
Install-Package DotNetDiag.HealthChecks.SurrealDb
Install-Package DotNetDiag.HealthChecks.System
Install-Package DotNetDiag.HealthChecks.Uris

Once the package is installed you can add the HealthCheck using the AddXXX IServiceCollection extension methods.

Preview and integration packages are published through GitHub Packages.

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks()
        .AddSqlServer(Configuration["Data:ConnectionStrings:Sql"])
        .AddRedis(Configuration["Data:ConnectionStrings:Redis"]);
}

Each HealthCheck registration supports also name, tags, failure status and other optional parameters.

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddHealthChecks()
        .AddSqlServer(
            connectionString: Configuration["Data:ConnectionStrings:Sql"],
            healthQuery: "SELECT 1;",
            name: "sql",
            failureStatus: HealthStatus.Degraded,
            tags: ["db", "sql", "sqlserver"]);
}

HealthCheck push results

HealthChecks include a push model to send HealthCheckReport results into configured consumers. The project DotNetDiag.HealthChecks.Publisher.ApplicationInsights, DotNetDiag.HealthChecks.Publisher.Datadog, DotNetDiag.HealthChecks.Publisher.Prometheus, DotNetDiag.HealthChecks.Publisher.Seq or DotNetDiag.HealthChecks.Publisher.CloudWatch define a consumers to send report results to Application Insights, Datadog, Prometheus, Seq or CloudWatch.

Package	Downloads	NuGet Latest	Issues	Notes
Application Insights
CloudWatch
Datadog
Prometheus Gateway				DEPRECATED
Seq

Include the package in your project:

install-package DotNetDiag.HealthChecks.Publisher.ApplicationInsights
install-package DotNetDiag.HealthChecks.Publisher.CloudWatch
install-package DotNetDiag.HealthChecks.Publisher.Datadog
install-package DotNetDiag.HealthChecks.Publisher.Prometheus
install-package DotNetDiag.HealthChecks.Publisher.Seq

Add publisher[s] into the IHealthCheckBuilder:

services
    .AddHealthChecks()
    .AddSqlServer(connectionString: Configuration["Data:ConnectionStrings:Sample"])
    .AddCheck<RandomHealthCheck>("random")
    .AddApplicationInsightsPublisher()
    .AddCloudWatchPublisher()
    .AddDatadogPublisher("myservice.healthchecks")
    .AddPrometheusGatewayPublisher();

HealthChecks Prometheus Exporter

If you need an endpoint to consume from prometheus instead of using Prometheus Gateway you could install DotNetDiag.HealthChecks.Prometheus.Metrics.

install-package DotNetDiag.HealthChecks.Prometheus.Metrics

Use the ApplicationBuilder extension method to add the endpoint with the metrics:

// default endpoint: /healthmetrics
app.UseHealthChecksPrometheusExporter();

// You could customize the endpoint
app.UseHealthChecksPrometheusExporter("/my-health-metrics");

// Customize HTTP status code returned(prometheus will not read health metrics when a default HTTP 503 is returned)
app.UseHealthChecksPrometheusExporter("/my-health-metrics", options => options.ResultStatusCodes[HealthStatus.Unhealthy] = (int)HttpStatusCode.OK);

HealthCheckUI

UI Changelog

The project HealthChecks.UI is a minimal UI interface that stores and shows the health checks results from the configured HealthChecks URIs.

For UI, we provide the following packages:

Package	Downloads	NuGet Latest	Issues	Notes
UI				ASP.NET Core UI viewer of ASP.NET Core HealthChecks
UI.Client				Mandatory abstractions to work with HealthChecks.UI
UI.Core
UI.Data				Data models and database context definition

To integrate HealthChecks.UI in your project you just need to add the HealthChecks.UI services and middlewares available in the package: DotNetDiag.HealthChecks.UI

using HealthChecks.UI.Core;
using HealthChecks.UI.InMemory.Storage;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services
            .AddHealthChecksUI()
            .AddInMemoryStorage();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app
            .UseRouting()
            .UseEndpoints(config => config.MapHealthChecksUI());
    }
}

This automatically registers a new interface on /healthchecks-ui where the SPA will be served.

Optionally, MapHealthChecksUI can be configured to serve its health API, webhooks API and the front-end resources in different endpoints using the MapHealthChecksUI(setup => { }) method overload. The default configured URLs for these endpoints can be found here

Important note: It is important to understand that the API endpoint that the UI serves is used by the frontend SPA to receive the result of all processed checks. The health reports are collected by a background hosted service and the API endpoint served at /healthchecks-api by default is the URL that the SPA queries.

Do not confuse this UI API endpoint with the endpoints we have to configure to declare the target APIs to be checked on the UI project in the appsettings HealthChecks configuration section

When we target applications to be tested and shown on the UI interface, those endpoints have to register the UIResponseWriter that is present on the DotNetDiag.HealthChecks.UI.Client as their ResponseWriter in the HealthChecksOptions when configuring MapHealthChecks method.

UI Polling interval

You can configure the polling interval in seconds for the UI inside the setup method. Default value is 10 seconds:

.AddHealthChecksUI(setupSettings: setup =>
{
    setup.SetEvaluationTimeInSeconds(5); // Configures the UI to poll for healthchecks updates every 5 seconds
});

UI API max active requests

You can configure max active requests to the HealthChecks UI backend api using the setup method. Default value is 3 active requests:

.AddHealthChecksUI(setupSettings: setup =>
{
    setup.SetApiMaxActiveRequests(1);
    //Only one active request will be executed at a time.
    //All the excedent requests will result in 429 (Too many requests)
});

UI Storage Providers

HealthChecks UI offers several storage providers, available as different nuget packages.

The current supported databases are:

Package	Downloads	NuGet Latest	Issues	Notes
InMemory
SqlServer
SQLite
PostgreSQL
MySql

All the storage providers are extensions of HealthChecksUIBuilder:

InMemory

services
    .AddHealthChecksUI()
    .AddInMemoryStorage();

Sql Server

services
    .AddHealthChecksUI()
    .AddSqlServerStorage("connectionString");

Postgre SQL

services
    .AddHealthChecksUI()
    .AddPostgreSqlStorage("connectionString");

MySql

services
    .AddHealthChecksUI()
    .AddMySqlStorage("connectionString");

Sqlite

services
    .AddHealthChecksUI()
    .AddSqliteStorage($"Data Source=sqlite.db");

UI Database Migrations

Database Migrations are enabled by default, if you need to disable migrations you can use the AddHealthChecksUI setup:

services
    .AddHealthChecksUI(setup => setup.DisableDatabaseMigrations())
    .AddInMemoryStorage();

Or you can use IConfiguration providers, like json file or environment variables:

"HealthChecksUI": {
  "DisableMigrations": true
}

Health status history timeline

By clicking details button in the healthcheck row, you can preview the health status history timeline:

Note: HealthChecks UI saves an execution history entry in the database whenever a HealthCheck status changes from Healthy to Unhealthy and viceversa.

This information is displayed in the status history timeline, but we do not perform purge or cleanup tasks in users' databases. In order to limit the maximum history entries that are sent by the UI API middleware to the frontend, you can do a database cleanup or set the maximum history entries served by endpoint using:

services.AddHealthChecksUI(setup =>
{
    // Set the maximum history entries by endpoint that will be served by the UI api middleware
    setup.MaximumHistoryEntriesPerEndpoint(50);
});

HealthChecksUI is also available as a docker image You can read more about HealthChecks UI Docker image.

Configuration

By default, HealthChecks return a simple Status Code (200 or 503) without the HealthReport data. If you want the HealthCheck-UI to show the HealthReport data from your HealthCheck, you can enable it by adding a specific ResponseWriter.

app
    .UseRouting()
    .UseEndpoints(config =>
    {
        config.MapHealthChecks("/healthz", new HealthCheckOptions
        {
            Predicate = _ => true,
            ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
        });
    });

WriteHealthCheckUIResponse is defined on the DotNetDiag.HealthChecks.UI.Client NuGet package.

To show these HealthChecks in HealthCheck-UI, they have to be configured through the HealthCheck-UI settings.

You can configure these Healthchecks and webhooks by using IConfiguration providers (appsettings, user secrets, env variables) or the AddHealthChecksUI(setupSettings: setup => { }) method can be used too.

Sample 2: Configuration using appsettings.json

{
  "HealthChecksUI": {
    "HealthChecks": [
      {
        "Name": "HTTP-Api-Basic",
        "Uri": "http://localhost:6457/healthz"
      }
    ],
    "Webhooks": [
      {
        "Name": "",
        "Uri": "",
        "Payload": "",
        "RestoredPayload": ""
      }
    ],
    "EvaluationTimeInSeconds": 10,
    "MinimumSecondsBetweenFailureNotifications": 60
  }
}

Sample 2: Configuration using setupSettings method:

services
    .AddHealthChecksUI(setupSettings: setup =>
    {
       setup.AddHealthCheckEndpoint("endpoint1", "http://localhost:8001/healthz");
       setup.AddHealthCheckEndpoint("endpoint2", "http://remoteendpoint:9000/healthz");
       setup.AddWebhookNotification("webhook1", uri: "http://httpbin.org/status/200?code=ax3rt56s", payload: "{...}");
    })
    .AddSqlServer("connectionString");

Note: The previous configuration section was HealthChecks-UI, but due to incompatibilies with Azure Web App environment variables, the section has been moved to HealthChecksUI. The UI is retro compatible and it will check the new section first, and fallback to the old section if the new section has not been declared.

1.- HealthChecks: The collection of health checks uris to evaluate.
2.- EvaluationTimeInSeconds: Number of elapsed seconds between health checks.
3.- Webhooks: If any health check returns a *Failure* result, this collections will be used to notify the error status. (Payload is the json payload and must be escaped. For more information see the notifications documentation section)
4.- MinimumSecondsBetweenFailureNotifications: The minimum seconds between failure notifications to avoid receiver flooding.

{
  "HealthChecksUI": {
    "HealthChecks": [
      {
        "Name": "HTTP-Api-Basic",
        "Uri": "http://localhost:6457/healthz"
      }
    ],
    "Webhooks": [
      {
        "Name": "",
        "Uri": "",
        "Payload": "",
        "RestoredPayload": ""
      }
    ],
    "EvaluationTimeInSeconds": 10,
    "MinimumSecondsBetweenFailureNotifications": 60
  }
}

Using relative URLs in Health Checks and Webhooks configurations (UI 3.0.5 onwards)

If you are configuring the UI in the same process where the HealthChecks and Webhooks are listening, from version 3.0.5 onwards the UI can use relative URLs, and it will automatically discover the listening endpoints by using server IServerAddressesFeature.

Sample:

//Configuration sample with relative URL health checks and webhooks
services
    .AddHealthChecksUI(setupSettings: setup =>
    {
       setup.AddHealthCheckEndpoint("endpoint1", "/health-databases");
       setup.AddHealthCheckEndpoint("endpoint2", "health-messagebrokers");
       setup.AddWebhookNotification("webhook1", uri: "/notify", payload: "{...}");
    })
    .AddSqlServer("connectionString");

You can also use relative URLs when using IConfiguration providers like appsettings.json.

Webhooks and Failure Notifications

If the WebHooks section is configured, HealthCheck-UI automatically posts a new notification into the webhook collection. HealthCheckUI uses a simple replace method for values in the webhook's Payload and RestorePayload properties. At this moment we support two bookmarks:

[[LIVENESS]] The name of the liveness that returns Down.

[[FAILURE]] A detail message with the failure.

[[DESCRIPTIONS]] Failure descriptions

Webhooks can be configured with configuration providers and also by code. Using code allows greater customization as you can setup you own user functions to customize output messages or configuring if a payload should be sent to a given webhook endpoint.

The web hooks section contains more information and webhooks samples for Microsoft Teams, Azure Functions, Slack and more.

Avoid Fail notification spam

To prevent you from receiving several failure notifications from your application, a configuration was created to meet this scenario.

services.AddHealthChecksUI(setup =>
{
    setup.SetNotifyUnHealthyOneTimeUntilChange(); // You will only receive one failure notification until the status changes.
});

UI Style and branding customization

Sample of dotnet styled UI

Since version 2.2.34, UI supports custom styles and branding by using a custom style sheet and css variables. To add your custom styles sheet, use the UI setup method:

app
    .UseRouting()
    .UseEndpoints(config =>
    {
        config.MapHealthChecksUI(setup =>
        {
            setup.AddCustomStylesheet("dotnet.css");
        });
    });

You can visit the section custom styles and branding to find source samples and get further information about custom css properties.

UI Configure HttpClient and HttpMessageHandler for Api and Webhooks endpoints

If you need to configure a proxy, or set an authentication header, the UI allows you to configure the HttpMessageHandler and the HttpClient for the webhooks and healtheck api endpoints. You can also register custom delegating handlers for the API and WebHooks HTTP clients.

services.AddHealthChecksUI(setupSettings: setup =>
{
    setup.ConfigureApiEndpointHttpclient((sp, client) =>
    {
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "supertoken");
    })
    .UseApiEndpointHttpMessageHandler(sp =>
    {
        return new HttpClientHandler
        {
            Proxy = new WebProxy("http://proxy:8080")
        };
    })
    .UseApiEndpointDelegatingHandler<CustomDelegatingHandler>()
    .ConfigureWebhooksEndpointHttpclient((sp, client) =>
    {
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "sampletoken");
    })
    .UseWebhookEndpointHttpMessageHandler(sp =>
    {
        return new HttpClientHandler()
        {
            Properties =
            {
                ["prop"] = "value"
            }
        };
    })
    .UseWebHooksEndpointDelegatingHandler<CustomDelegatingHandler2>();
})
.AddInMemoryStorage();

UI Kubernetes Operator

If you are running your workloads in kubernetes, you can benefit from it and have your healthchecks environment ready and monitoring in seconds.

You can get for information in our HealthChecks Operator docs

UI Kubernetes automatic services discovery

HealthChecks UI supports automatic discovery of k8s services exposing pods that have health checks endpoints. This means, you can benefit from it and avoid registering all the endpoints you want to check and let the UI discover them using the k8s api.

You can get more information here

HealthChecks as Release Gates for Azure DevOps Pipelines

HealthChecks can be used as Release Gates for Azure DevOps using this Visual Studio Market place Extension.

Check this README on how to configure it.

Protected HealthChecks.UI with OpenID Connect

There are some scenarios where you can find useful to restrict access for users on HealthChecks UI, maybe for users who belong to some role, based on some claim value etc.

We can leverage the ASP.NET Core Authentication/Authorization features to easily implement it. You can see a fully functional example using IdentityServer4 here but you can use Azure AD, Auth0, Okta, etc.

Check this README on how to configure it.

Tutorials, demos and walkthroughs on ASP.NET Core HealthChecks

Contributing

DotNetDiag HealthChecks wouldn't be possible without the time and effort of its contributors. The team is made up of Unai Zorrilla Castro @unaizorrilla, Luis Ruiz Pavón @lurumad, Carlos Landeras @carloslanderas, Eduard Tomás @eiximenis, Eva Crespo @evacrespob and Ivan Maximov @sungam3r.

Thanks to all the people who already contributed!

If you want to contribute to the project and make it better, your help is very welcome. You can contribute with helpful bug reports, features requests, submitting new features with pull requests and also answering questions.

Read and follow the Don't push your pull requests
Follow the code guidelines and conventions.
New features are not only code, tests and documentation are also mandatory.
PRs with Ups for grabs and help wanted tags are good candidates to contribute.

Name		Name	Last commit message	Last commit date
Latest commit History 2,549 Commits
.config		.config
.github		.github
assets		assets
build		build
deploy/operator		deploy/operator
docs		docs
extensions		extensions
samples		samples
src		src
test		test
.dockerignore		.dockerignore
.editorconfig		.editorconfig
.env		.env
.gitignore		.gitignore
AGENTS.md		AGENTS.md
AspNetCore.Diagnostics.HealthChecks.sln		AspNetCore.Diagnostics.HealthChecks.sln
Directory.Build.props		Directory.Build.props
Directory.Build.targets		Directory.Build.targets
Directory.Packages.props		Directory.Packages.props
LICENSE		LICENSE
Nuget.config		Nuget.config
README.md		README.md
build-docker-image.ps1		build-docker-image.ps1
build-operator-image.ps1		build-operator-image.ps1
docker-compose.yml		docker-compose.yml

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

DotNetDiag HealthChecks

Sections

HealthChecks

HealthChecks UI

HealthChecks UI and Kubernetes

HealthChecks and Devops

HealthChecks Tutorials

Docker images

Health Checks

HealthCheck push results

HealthChecks Prometheus Exporter

HealthCheckUI

UI Polling interval

UI API max active requests

UI Storage Providers

UI Database Migrations

Health status history timeline

Configuration

Sample 2: Configuration using appsettings.json

Sample 2: Configuration using setupSettings method:

Using relative URLs in Health Checks and Webhooks configurations (UI 3.0.5 onwards)

Webhooks and Failure Notifications

UI Style and branding customization

Sample of dotnet styled UI

UI Configure HttpClient and HttpMessageHandler for Api and Webhooks endpoints

UI Kubernetes Operator

UI Kubernetes automatic services discovery

HealthChecks as Release Gates for Azure DevOps Pipelines

Protected HealthChecks.UI with OpenID Connect

Tutorials, demos and walkthroughs on ASP.NET Core HealthChecks

Contributing

About

Uh oh!

Releases 8

Contributors

Languages

Folders and files

Latest commit

History

Repository files navigation

DotNetDiag HealthChecks

Sections

HealthChecks

HealthChecks UI

HealthChecks UI and Kubernetes

HealthChecks and Devops

HealthChecks Tutorials

Docker images

Health Checks

HealthCheck push results

HealthChecks Prometheus Exporter

HealthCheckUI

UI Polling interval

UI API max active requests

UI Storage Providers

UI Database Migrations

Health status history timeline

Configuration

Sample 2: Configuration using appsettings.json

Sample 2: Configuration using setupSettings method:

Using relative URLs in Health Checks and Webhooks configurations (UI 3.0.5 onwards)

Webhooks and Failure Notifications

UI Style and branding customization

Sample of dotnet styled UI

UI Configure HttpClient and HttpMessageHandler for Api and Webhooks endpoints

UI Kubernetes Operator

UI Kubernetes automatic services discovery

HealthChecks as Release Gates for Azure DevOps Pipelines

Protected HealthChecks.UI with OpenID Connect

Tutorials, demos and walkthroughs on ASP.NET Core HealthChecks

Contributing

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases 8

Contributors 0

Languages

Contributors