Wolverine.CritterWatch

Wolverine.CritterWatch is the NuGet package you install in each service you want CritterWatch to monitor. It plugs into the Wolverine runtime, publishes telemetry to the console, and handles the operator commands the console sends back.

This section is the integration reference — what to install, how to register it, and what to expect at runtime.

What it does

Once registered:

• Publishes telemetry once per second. Node lifecycle, agent assignments, endpoint health, persistence counts, projection shard state — all batched and sent over your existing Wolverine transport.
• Handles inbound commands. Replay DLQ messages, pause listeners, rebuild projections, add tenants, and the rest of the command set. The handlers are registered automatically — you don't write them.
• Probes agent health every 60 seconds. Catches silent agent failures that don't fire reactive callbacks.
• Reports your service's capabilities. Registered handlers, endpoints, message stores, event stores, multi-tenancy mode — what CritterWatch needs to render the service's pages.

What it costs

The runtime impact is negligible:

• Hot-path overhead per event: a single lock-free queue push. No serialization, no I/O.
• Publish overhead: one batched message per second, regardless of event volume. A flat 1Hz publish rate.
• Memory: a small ring buffer of pending changes plus a snapshot of current endpoint / shard state. Single-digit megabytes.
• No new database connections. Reuses your existing Wolverine transport.
• No new ports. Same transport in, same transport out.

What it doesn't change

• Your handlers, aggregates, and domain code stay the same. No annotations, no base classes, no decorators.
• No schema changes. CritterWatch never adds tables to your application's database.
• No additional processes. It runs in your existing service process.

Pages in this section

• Registration — installing and registering it in your service.
• Inbound Commands — every command the console can send, with the C# record signatures and minimal call examples.
• Outbound Events — what the service publishes back. Useful when you want to consume the same telemetry from your own infrastructure.
• Observer & Telemetry — what gets reported, on what cadence, and what to do when telemetry stops flowing.

License

CritterWatch has two distinct licenses that govern different pieces. This page is about the monitored-side library; the console is governed separately.

Piece	License	Where it runs
Wolverine.CritterWatch (this package)	MIT — no license key required	In every service you monitor
CritterWatch console (CritterWatch.Services)	Free / Professional / Enterprise tier — see Licensing	The dedicated console process

Wolverine.CritterWatch ships under the MIT license. You can install it in any production service regardless of which console tier you run — there is no license-key requirement on the monitored side, and the library doesn't reach back to the console to validate anything before publishing telemetry.

Some operator commands (DLQ replay, projection rebuild, tenant operations, etc.) ARE gated on the console's license tier. When an operator clicks one of those buttons:

• The console's tier check runs first; if the tier doesn't cover the action, the UI button stays disabled and the HTTP API refuses the call.
• If the console allows it, the command travels over your transport into your monitored service.
• The matching handler on the monitored side calls LicenseGuard.IsOperationAllowed() and throws LicenseRequiredException if the per-action gate is closed — defense-in-depth so a misconfigured console can't bypass tier enforcement at the bus level.

The MIT license on the library and the tier model on the console are two independent surfaces. Embedding Wolverine.CritterWatch in a service doesn't subject that service to the console's tier terms, and standing up a Professional / Enterprise console doesn't change what shipping Wolverine.CritterWatch to your customers means for them.