Heartbeats
Wolverine can periodically emit a WolverineHeartbeat message from each running
node so that external monitoring tools (for example
CritterWatch) can detect when a node
goes dark. Heartbeats are off by default and are opted-in through
EnableHeartbeats.
Quickstart
using Wolverine;
await Host.CreateDefaultBuilder()
.UseWolverine(opts =>
{
// Enable with the default 30-second cadence
opts.EnableHeartbeats();
// ...or override the interval
// opts.EnableHeartbeats(TimeSpan.FromSeconds(10));
// Route heartbeats wherever the dashboard listens. Without a publish
// rule the heartbeat is local-only and does nothing if no in-process
// handler subscribes.
opts.PublishMessage<Wolverine.Runtime.Heartbeat.WolverineHeartbeat>()
.ToRabbitExchange("monitoring");
})
.RunOasisAsync();What gets sent
Each heartbeat carries the bare minimum a monitor needs to attribute it back to a node:
| Field | Source |
|---|---|
ServiceName | WolverineOptions.ServiceName |
NodeNumber | WolverineOptions.Durability.AssignedNodeNumber |
SentAt | UTC timestamp captured at publish |
Uptime | Elapsed time since the heartbeat service started |
The publish goes through Wolverine’s normal routing pipeline — apply
PublishMessage, Publish().To*, or any other publish rule the same way you
would for any application event.
Configuration
HeartbeatPolicy lives at WolverineOptions.Heartbeat:
opts.Heartbeat.Enabled = false; // disable without removing registration
opts.Heartbeat.Interval = 5.Seconds(); // override the cadenceEnabled = false causes the hosted service to exit at startup, which is the
recommended way to suppress heartbeats per environment (e.g. local development)
without altering the registration.
Where this fits
Heartbeats answer “is this node still alive?” but say nothing about whether listeners or transports are healthy. Pair them with the existing durability and node health features for a fuller monitoring story.