GM.HealthChecks 1.0.0

<p align="center"> <img src="https://raw.githubusercontent.com/gmetskhvarishvili/GM.HealthChecks/master/icon.png" alt="GM.HealthChecks" width="140" height="140" /> </p>

GM.HealthChecks

Standardized health checks for the GM.* ecosystem — a thin, consistent layer over Microsoft.Extensions.Diagnostics.HealthChecks. One AddGMHealthChecks() + MapGMHealthChecks() gives you /health/live, /health/ready and /health/startup with a shared liveness / readiness / startup tag convention and consistent JSON (status, per-check durations, tags). Add checks for the infra you actually use via small provider packages. Targets .NET 10.

Packages

Core has no infrastructure dependencies; each provider package brings exactly one. They version and release together (lockstep):

Why the split? A service that only wants a liveness probe shouldn't pull in EF Core, RabbitMQ and Redis. Take GM.HealthChecks plus only the providers you use.

dotnet add package GM.HealthChecks
dotnet add package GM.HealthChecks.EntityFramework   # if you want the DB check, etc.

Quick start

using GM.HealthChecks;
using GM.HealthChecks.EntityFramework;
using GM.HealthChecks.Caching;
using GM.HealthChecks.Messaging;
using GM.HealthChecks.DistributedLock;

builder.Services.AddGMHealthChecks()          // liveness self-check + JSON/endpoint options
    .AddGMDatabaseCheck<AppDbContext>()        // GM.HealthChecks.EntityFramework
    .AddGMCacheCheck()                         // GM.HealthChecks.Caching
    .AddGMMessagingCheck()                     // GM.HealthChecks.Messaging
    .AddGMDistributedLockCheck()               // GM.HealthChecks.DistributedLock
    .AddGMHttpCheck("kyc-vendor", new Uri("https://kyc.example.com/status")); // core

var app = builder.Build();
app.MapGMHealthChecks();                        // maps /health/live, /health/ready, /health/startup
app.Run();

Including/excluding checks is compositional — add only the ones a given service needs. Every AddGM…Check also accepts a custom name and tags, so you can re-tag a check (e.g. move it out of readiness) per service.

The convention

Every infra check is tagged ["ready", "startup"] by default (HealthTags.Dependency); the built-in self-check is tagged ["live"]. Status codes follow the ASP.NET Core default: Healthy/Degraded → 200, Unhealthy → 503.

JSON response

{
  "status": "Healthy",
  "totalDurationMs": 12.4,
  "checks": [
    { "name": "gm:database", "status": "Healthy", "durationMs": 5.1, "tags": ["ready", "startup"] },
    { "name": "gm:cache",    "status": "Healthy", "durationMs": 1.3, "tags": ["ready", "startup"] }
  ]
}

Error text is omitted by default (it can leak internals); set GMHealthChecksOptions.IncludeExceptionDetails = true only where the endpoint isn't public.

Interfaces & key types

• HealthTags — Liveness / Readiness / Startup constants + the Dependency default array.
• GMHealthChecksOptions — endpoint paths (LivePath / ReadyPath / StartupPath), IncludeDetails, IncludeExceptionDetails.
• GMHealthResponseWriter — the shared JSON writer used by all three endpoints.
• Checks (all implement the standard IHealthCheck): SelfHealthCheck, HttpDependencyHealthCheck, DbContextHealthCheck<TContext>, CacheHealthCheck, RabbitMqHealthCheck, DistributedLockHealthCheck.
• Registration: AddGMHealthChecks() returns the standard IHealthChecksBuilder, and each provider is an extension on it — so it composes with the rest of the ASP.NET Core health-check ecosystem.

How the infra checks work

• Database — context.Database.CanConnectAsync() on your TContext (any EF Core provider).
• Cache — a Set → Get → Remove round-trip through GM.Caching's ICacheService, so it verifies whatever backend is registered (in-memory or Redis).
• RabbitMQ — opens a short-lived connection using GM.Messaging's configured MessagingOptions.
• Distributed lock — acquires and releases a unique probe lock via IDistributedLock.
• HTTP — a HEAD (or configured method) to an external URL; 2xx (or a specified status) = healthy.

On a UI dashboard

GM.HealthChecks intentionally ships JSON endpoints only — no bundled dashboard. The trade-offs considered:

• JSON only (chosen) — zero extra dependencies, works with Kubernetes probes and any external monitor (Grafana, Datadog, Uptime, …). The status is machine-readable and already sufficient.
• AspNetCore.HealthChecks.UI — a full dashboard with history, but a heavy third-party dependency with its own storage/polling/config and a larger surface to secure. Not worth baking into every consumer.
• A custom minimal HTML page — feasible, but it's UI scope creep for a library whose job is to report status, and any real dashboard belongs in your observability stack.

If you want a dashboard, point your existing monitoring at /health/ready — the JSON is designed for exactly that. (A dedicated GM.HealthChecks.UI provider could be added later without touching core.)

Repository layout

GM.HealthChecks/                  # conventions, endpoints, JSON writer, HTTP check
GM.HealthChecks.EntityFramework/  # AddGMDatabaseCheck<TContext>
GM.HealthChecks.Caching/          # AddGMCacheCheck
GM.HealthChecks.Messaging/        # AddGMMessagingCheck
GM.HealthChecks.DistributedLock/  # AddGMDistributedLockCheck
tests/GM.HealthChecks.Tests/      # xUnit tests

Building & testing

dotnet build -c Release
dotnet test  -c Release

Releasing

Versioning is automated from Conventional Commits — see CONTRIBUTING.md. All five packages share one version (Directory.Build.props) and publish together to nuget.org on each release.

License

MIT — see LICENSE.