Skip to content

Health Checks Aggregator Template (ConnectSoft.HealthChecksAggregatorTemplate)

Layer 3 host focused on aggregating health status from many downstream HTTP health endpoints, exposing a Health Checks UI, JSON APIs, readiness gate strategies, webhook notifications, and dependency graph data. It extends ConnectSoft.BaseTemplate via the base-template/ git submodule with a narrower optional stack than the full Microservice Template.

Documentation map

Section Purpose
Getting Started Install, first configuration
Parameters dotnet new (see also Features)
Solution structure Projects
Architecture Aggregation + DI
Features APIs, gates, webhooks
Configuration HealthCheckAggregator
Authentication Securing endpoints if enabled
Resiliency Polling, cache, retries
Testing Tests
Development Extend aggregator
Use cases Ops scenarios
Runbook Deploy, probes

Use this template for platform / SRE visibility (single pane of glass, orchestration readiness, alerting). Use the Microservice Template for domain services and business APIs.

Capabilities (summary)

  • Poll configured downstream services (retry, timeout, cache, tags).
  • Health Checks UI dashboard (SQL Server or InMemory storage for history).
  • REST API under /api/health/* (aggregated status, per-service, by tag, dependencies, readiness).
  • Readiness strategies: AllHealthy, CriticalOnly, PercentageThreshold, TagBased.
  • Webhooks (e.g. Slack, Microsoft Teams, custom URLs) with payload templates.
  • Standard probes: /health, /alive, /startup (Kubernetes-friendly).

Technical model

Aspect Detail
Workload type Platform / SRE visibility host—not a DDD microservice
Extension point Template-specific registration (e.g. HealthChecksAggregatorRegistration) after MicroserviceRegistrationBase
Data plane HTTP(S) polls to downstream HealthCheckUrl values; optional Redis / SQL for UI history
Control plane appsettings / env vars under HealthCheckAggregator (see Configuration, Features)

Downstream targets are usually Microservice or other hosts exposing ASP.NET health endpoints compatible with your polling configuration.

Typical deployment patterns

  • Kubernetes: liveness on /alive; readiness on /health or GET /api/health/readiness when gate logic must include downstream criticality.
  • Docker Compose: same paths; wire dependencies so the aggregator starts after sample backends or tolerates degraded startup.
  • Alerting: webhooks forward unhealthy transitions to Slack/Teams or custom incident flows.

Full parameter tables, config keys, and endpoint list: Features.

Canonical deep dive: ConnectSoft.HealthChecksAggregatorTemplate README and repo Docs/Index.md.

dotnet new

  • Installer: ConnectSoft.HealthChecksAggregatorTemplate.Installer
  • Short name: connectsoft-healthchecks-aggregator
dotnet new install ConnectSoft.HealthChecksAggregatorTemplate.Installer
dotnet new connectsoft-healthchecks-aggregator -n MyHealthAggregator

Typical first run (after scaffold): open the Application project appsettings.json and configure HealthCheckAggregator:Services (name, URL, tags, criticality). See Features and the repo README.

Default URLs (typical Docker / local)

Paths depend on template parameters; defaults align with the README:

Surface Default (example)
Health Checks UI /health-ui
Aggregated API /api/health
Liveness /alive
Readiness (ASP.NET) /health
Readiness gate JSON GET /api/health/readiness

For Kubernetes, map liveness to /alive and readiness to /health or to /api/health/readiness when you want readiness tied to the aggregator’s gate strategy (see README examples).

Documentation

Repository layout uses root-level Docs/ and Application projects for consistency with other extended templates; see the templates registry.