Healthie.NET.Alerting
4.1.2
Prefix Reserved
dotnet add package Healthie.NET.Alerting --version 4.1.2
NuGet\Install-Package Healthie.NET.Alerting -Version 4.1.2
<PackageReference Include="Healthie.NET.Alerting" Version="4.1.2" />
<PackageVersion Include="Healthie.NET.Alerting" Version="4.1.2" />
<PackageReference Include="Healthie.NET.Alerting" />
paket add Healthie.NET.Alerting --version 4.1.2
#r "nuget: Healthie.NET.Alerting, 4.1.2"
#:package Healthie.NET.Alerting@4.1.2
#addin nuget:?package=Healthie.NET.Alerting&version=4.1.2
#tool nuget:?package=Healthie.NET.Alerting&version=4.1.2
Healthie.NET.Alerting
▶ Live demo — board.healthie-dotnet.dev — a read-only Healthie.NET dashboard watching real status pages (Anthropic, OpenAI, GitHub, Cloudflare, and more), built from these packages. Full documentation at healthie-dotnet.dev.
Turns health changes into alerts and delivers them, without letting a delivery problem become a monitoring problem.
Installation
dotnet add package Healthie.NET.Alerting
Usage
using Healthie.Alerting;
builder.Services
.AddHealthie(typeof(Program).Assembly)
.AddHealthieAlerts()
.AddHealthieSlackAlerts(new Uri("https://hooks.slack.com/services/..."))
.AddHealthiePagerDutyAlerts("your-integration-key");
Add as many sinks as you like; each gets every alert. For anywhere none of them reaches, implement IAlertSink and register it — the dispatcher finds every one that is registered.
Where alerts go
| Sink | Registered with | Sends |
|---|---|---|
| Slack | AddHealthieSlackAlerts(url) |
A message with a colour-coded attachment, to an incoming webhook |
| Microsoft Teams | AddHealthieMicrosoftTeamsAlerts(url) |
An Adaptive Card, to a Workflows URL |
| PagerDuty | AddHealthiePagerDutyAlerts(key) |
An Events API v2 trigger, resolved when the checker recovers |
| Anything else | AddHealthieWebhookAlerts(url) |
The generic JSON payload below |
Three of these are not the webhook wearing a hat. Slack, Teams and PagerDuty each reject arbitrary JSON, so posting the generic payload at them fails — which is why reaching them used to need something in between to reshape it. None needs a dependency this package did not already have, so they are here rather than in a package each.
Teams takes the Workflows URL, not an Office 365 connector. Microsoft has retired those connectors along with the MessageCard payload they accepted; in Teams, add a Workflow to the channel and use the URL it gives you.
PagerDuty closes what it opens. A failure raises an incident keyed on the checker, and the recovery resolves that same incident rather than posting a second message saying everything is fine. A checker flapping between suspicious and unhealthy stays one incident, because the deduplication key deliberately leaves out the health and the time. Suspicious maps to warning rather than critical — it is the state that means "failing, but not past the threshold yet", and paging on it would defeat having a threshold.
Configure any sink's HttpClient — its timeout, its handler, an auth header — by naming its HttpClientName constant in your own AddHttpClient call.
What alerts
By default, a checker becoming unhealthy, and a checker recovering. Not every check — only a change of health.
.AddHealthieAlerts(options =>
{
options.MinimumSeverity = PulseCheckerHealth.Suspicious; // include early warnings
options.SendRecoveries = false; // opens only, no all-clears
options.DeduplicationWindow = TimeSpan.FromMinutes(15);
})
MinimumSeverity defaults to Unhealthy. Suspicious is the state a checker passes through on its way there, so alerting on it by default would page somebody for every blip the failure threshold exists to absorb. Lower it when the early warning is the point — a certificate inside its expiry window is suspicious for weeks and never becomes unhealthy until it is too late to act.
DeduplicationWindow defaults to five minutes. A component on the edge of working flaps, and every flip is a genuine health change; without a window a checker running every second could send a hundred alerts about one incident.
Delivery cannot hurt the checks
This is the part worth knowing. Alerting subscribes to state changes rather than sitting inside the check, so:
- A sink that throws is logged and skipped. The other sinks still get the alert, and the next alert still goes out.
- A sink that hangs is abandoned at
DeliveryTimeout(ten seconds by default). - A slow sink never delays a check. Raising the event only queues; every delivery happens on the dispatcher's own loop.
- A backed-up queue drops rather than grows.
QueueCapacitybounds it at 1024, and drops are counted and logged. An unbounded queue would trade a delivery problem for a memory leak inside the process being monitored.
None of it can mark a component unhealthy. A checker reports on the thing it watches, and a broken webhook is not that thing.
Webhook payload
{
"checker": "Contoso.Api.DatabasePulseChecker",
"displayName": "Primary database",
"group": "data",
"tags": ["cloud", "primary"],
"status": "Unhealthy",
"previousStatus": "Healthy",
"isRecovery": false,
"message": "Connection timed out after 5s.",
"occurredAt": "2026-07-29T11:04:22.1234567Z",
"deduplicationKey": "healthie:Contoso.Api.DatabasePulseChecker"
}
deduplicationKey identifies the ongoing incident, not the occurrence — it deliberately excludes the health and the time, so an incident tracker keyed on it closes the same incident it opened rather than accumulating one per transition.
Configure the client — timeout, handler, an auth header — by naming WebhookAlertSink.HttpClientName in your own AddHttpClient call.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- Healthie.NET.Abstractions (>= 4.1.2)
- Microsoft.Extensions.Http (>= 10.0.11)
-
net8.0
- Healthie.NET.Abstractions (>= 4.1.2)
- Microsoft.Extensions.Http (>= 10.0.11)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
### Fixed
- The dashboard event-log and about dialogs now move focus inside, keep keyboard focus contained,
close with Escape, and restore focus to the control that opened them.
- Dashboard checker rows now expose selection as a real button alongside their action buttons,
removing nested interactive controls while preserving whole-row pointer selection.
- A dashboard state-provider failure now shows a recoverable unavailable state with a retry action
instead of looking like an empty installation with no registered checkers.
- The Blazor sample now keeps the dashboard stylesheet in its static host head, preventing an
unstyled flash while the interactive head reconnects on a slow network.
- HTTP checker display names and result messages now omit URI user information, query strings, and
fragments, server-controlled reason phrases, and transport exception details, preventing embedded
credentials and tokens from reaching stored history, alerts, logs, or the dashboard while requests
still use the complete configured URI.
- Alert-history persistence now loads durable history before its first post-restart write and
coalesces changes raised during a slow state-provider write into one latest-state follow-up. This
preserves earlier alerts without duplicating the new one and avoids an unbounded queue of tasks
and redundant full-history writes during alert bursts.
- The Web API sample maps its unauthenticated management API and mutation-enabled MCP endpoint only
in Development, so deploying the sample with a production environment no longer exposes those
local demonstration surfaces. Liveness and readiness probes remain available.
- History clearing and startup trimming now use optimistic concurrency, so they no longer overwrite
a check result or setting changed by another replica between the read and write.
- Leader election now serializes schedule changes with leadership transitions and reconciles every
registered checker's persisted active state and schedule through a bulk read on lease renewal. A
pause or cadence change made through another replica now reaches the leader, a fresh leader
removes inactive durable jobs left by the previous process, and reconciliation runs with bounded
concurrency while an independent lease heartbeat prevents slow scheduler calls from expiring an
otherwise healthy leader. Partial and cancelled transitions remain tracked until cleanup succeeds,
and shutdown does not release the lease over work it could not stop.
- CosmosDB multi-state reads now use `ReadManyItemsAsync`, avoiding one sequential network round
trip per checker during dashboard loads and leader renewal.
- The in-memory lease provider now returns exactly one winner when replicas contend concurrently.
- Coravel, Hangfire, Temporal, and the leader-election decorator now validate schedules before they
are persisted. Cronos expressions requiring an absent jitter seed are reported as validation
failures instead of escaping as server errors. The built-in timer also rejects periods outside
`PeriodicTimer`'s supported range before replacing a working schedule.
- Temporal now preserves Healthie.NET's six-field, leading-seconds cron meaning by translating it
to Temporal's seven-field seconds form. It rejects Cronos-only relative-day and descending-range
expressions whose Temporal meaning differs, and fixed periods outside Temporal's supported range,
before an existing schedule is removed.
- Uptime recording now starts a new observation segment on the first fresh result after a process
restart, even when its health matches persisted state. Time while no process was observing the
checker remains unknown, and a transition that finds the bounded queue full is retried by the next
fresh result.
Full changelog: https://github.com/ivanvyd/Healthie.NET/blob/v4.1.2/CHANGELOG.md