Healthie.NET.Alerting
4.1.1
Prefix Reserved
dotnet add package Healthie.NET.Alerting --version 4.1.1
NuGet\Install-Package Healthie.NET.Alerting -Version 4.1.1
<PackageReference Include="Healthie.NET.Alerting" Version="4.1.1" />
<PackageVersion Include="Healthie.NET.Alerting" Version="4.1.1" />
<PackageReference Include="Healthie.NET.Alerting" />
paket add Healthie.NET.Alerting --version 4.1.1
#r "nuget: Healthie.NET.Alerting, 4.1.1"
#:package Healthie.NET.Alerting@4.1.1
#addin nuget:?package=Healthie.NET.Alerting&version=4.1.1
#tool nuget:?package=Healthie.NET.Alerting&version=4.1.1
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.1)
- Microsoft.Extensions.Http (>= 10.0.11)
-
net8.0
- Healthie.NET.Abstractions (>= 4.1.1)
- 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 cropped its own rows on anything narrower than a laptop.** The row and its column
header share one track definition, and two rules overrode it: a read-only board drops the controls
column, and a narrow viewport folds the row down to three. Written as separate rule sets they
fought on specificity, and `.hpm-list--readonly .hpm-row` outranks a `.hpm-row` inside a media
query -- so on a read-only board the fold never applied at any width. Every row was drawn with
five tracks demanding 556px inside a 342px phone: 214px of columns clipped off the right, the name
squeezed to its 160px minimum to make room for columns that were not visible anyway, and no
scrollbar to reach them, because the overflow was clipped rather than scrolled. The definition is
now a single custom property on the list, which is the one element both variants already sit on,
so the fold cannot be outranked.
- **The last column was clipped on an ordinary 1280 laptop, read-only or not.** The detail panel
moved below the list at 1100px, but a full row needs a 706px column and the list only reaches that
at 1402px of viewport -- so between those two the three columns fitted the window while the middle
one no longer fitted a row. That threshold is now 1400px, calibrated on the editable board, which
is the wider of the two and the default.
- **Group and tag chips were sliced down the middle on a phone.** They sit on the row's sub-line,
which truncates with `text-overflow: ellipsis` -- and that ellipsizes text, not an inline-flex
pill, so a chip was cut mid-shape instead. The folded row has vertical room the wide one does not,
so the line now wraps there, exactly as it already does on a card.
- **Cards lost their rate, sparkline and last-checked time on a phone.** The three cells were hidden
for every layout below 820px, but only the row layout was short of width; a card stacks them into
areas down its own length, where they fit. They are now hidden for the row layout alone.
### Changed
- **The packages point at [healthie-dotnet.dev](https://healthie-dotnet.dev/).** `PackageProjectUrl`
is the landing site rather than the repository, because NuGet renders it as the package's "Project
website" and a reader who clicks it wants documentation and the live board, not a source tree.
`RepositoryUrl` still points at GitHub, so Source Link and NuGet's own source link are unaffected.
Every package README now links the documentation site alongside the live demo, which moved to
[board.healthie-dotnet.dev](https://board.healthie-dotnet.dev/).
- **Releases carry build provenance.** The release workflow attests which workflow, at which commit,
produced each package, so `gh attestation verify <package>.nupkg --repo ivanvyd/Healthie.NET`
proves a download came from this repository. The SBOM already said what went into a package; this
says who built it, which is the half a tampered build would otherwise be free to restate.
- The repository README leads with a screenshot rather than a 10MB animation, and `Healthie.NET.Redis`
gained the header every other package README already had.
Full changelog: https://github.com/ivanvyd/Healthie.NET/blob/v4.1.1/CHANGELOG.md