Introduction
CritterWatch is a monitoring, management, and insight console for distributed systems built on the Critter Stack — Wolverine, Marten, and Polecat. It gives you a single screen for every question that comes up building and running these systems — from understanding how a service is wired at development time to operating it in production — and exposes the same data to your AI assistant over MCP.
Problems CritterWatch solves
If your team has hit any of these in the last six months, this is the right tool:
"I just inherited this service — how is it actually wired?" The Event Model tab renders the command → event → aggregate → projection flow as a swim-lane and flags where your declared model has drifted from the generated code. The Topology page draws the cross-service message graph, and each HTTP endpoint shows its actual generated handler pipeline. CritterWatch reads your application's structure back to you — the ground truth, not your mental model.
"My projections are stalled — how do I find them?" The Projections page lists every shard with current sequence, high-water mark, and lag. Stalled shards are color-coded; click in to see lag history and (if needed) restart, rebuild, or rewind from the UI.
"Messages are piling up in the dead letter queue — how do I investigate and replay them?" The Dead Letter Queue page is a unified view across every service and message store. Filter by service, message type, exception type, or tenant. Click a row to see the message body, full stack trace, and processing history. Replay one message, replay everything matching the filter, edit-and-replay (fix bad data and try again), or discard. It's the page most operators end up living on.
"I'm seeing back-pressure warnings — what does that mean and what should I do?" The Listeners page shows every endpoint's status — Accepting, TooBusy (back pressure), Latched (circuit breaker tripped), Stopped, etc. The detail panel shows the configured thresholds, the live failure rate, and the per-endpoint controls (pause / drain / restart, edit buffering limits, edit circuit breaker).
"My service looks healthy but isn't actually processing messages." A node can be heartbeating, leader-elected, and green on every dashboard while one of its listeners has silently stopped consuming — a transport channel that died without an error, a tripped circuit, a queue nobody is draining. Node-liveness checks miss this entirely, because the node is fine — it's the listener that's stuck. CritterWatch tracks each listener's health independently (status, last-activity, broker queue depth) and flags the unambiguous "messages waiting, nothing consuming" signature, then lets you recover it — force-restart a stuck listener, or pause and resume consumption across the entire application, durably (stop pulling from a queue on every node while a downstream dependency is down, and stay paused through restarts until you resume). This listener-level health view — distinct from node liveness — is something raw broker dashboards and process health checks can't give you. See Listeners & Endpoints and the downstream-system-broken scenario.
"How do I set up alerts so I know before users complain?"Alerts ship with sensible defaults plus per-service and per-message-type overrides. Configure them in Alert Configuration; they fan out to Slack, Discord, or Teams via the channels in Settings.
"A node went down — what happened to its work?" The Cluster tab shows nodes with heartbeat dots and assigned-agent counts. When a node goes silent, the dot turns amber then red. The leader rebalances the agents to live nodes; you can also eject a stuck node manually so the rebalance happens immediately.
"I need to add a new tenant to the system at runtime." Multi-tenant services with DynamicMultiple cardinality get a Tenants tab with Add / Disable / Enable / Remove / Hard delete. The console handles the runtime database addition + Marten schema creation in a single click.
"How do I verify my message routing is correct after a deployment?" The Messaging tab lists every message type the service knows how to handle, with the live throughput, exec time, and DLQ rate. The Topology page draws the publish/handle graph across services so you can see which services produce a message and which handle it.
"Can my AI assistant inspect and operate this for me?" CritterWatch ships an MCP server: point Claude or any MCP agent at one endpoint and it can query every monitored service — spans, projection lag, dead letters, alerts, metrics — and take action, tenant-scoped and RBAC-gated. Pair it with the JasperFx AI Skills so your agent knows how to use it.
What it doesn't do
CritterWatch is purpose-built for the Critter Stack — Wolverine messaging, Marten event sourcing, EF Core (when used with Wolverine integration), and Polecat. It is not:
- A general-purpose APM (use OpenTelemetry + your existing tracing backend; CritterWatch has trace provider links to jump from a saga or handler to a Jaeger trace).
- A log aggregator (use your existing log pipeline).
- A metrics dashboard for non-message-driven systems.
- An alternative to Kubernetes or your application platform.
It complements those tools — it doesn't replace them.
How it fits in
CritterWatch Server; CritterWatch Server <-> N Wolverine Services (bidirectional); CritterWatch Server --> Jaeger, Prometheus, AppInsights. To embed: save the export to docs/public/critterwatch-architecture.svg (or .png) and keep the .excalidraw source alongside, then REPLACE the mermaid block below with:
 -->
Adding CritterWatch to an existing Wolverine application takes a single NuGet package and a few lines of configuration. There are no schema changes to your services and no new external dependencies — the console reuses the Wolverine transport you already have.
CritterWatch is tested against RabbitMQ, AWS SQS, Azure Service Bus, and Wolverine's standalone HTTP transport, and is usable with any other Wolverine-supported messaging transport. The console itself is a drop-in NuGet package for an ASP.NET Core website, so you can secure it with any authentication scheme ASP.NET Core supports.
For the deployment-side picture, see How CritterWatch Works.
Capabilities at a glance
| Capability | Page |
|---|---|
| System-wide health summary | Dashboard |
| Per-service detail (nodes, agents, endpoints, metrics, tenants, HTTP) | Services |
| Dead letter queue management | Dead Letters |
| Async projection monitoring + lifecycle controls | Projections |
| Endpoint health, circuit breakers, back pressure | Listeners & Endpoints |
| Alert configuration and lifecycle | Alerts · Alert Configuration |
| Scheduled message management | Scheduled Messages |
| Inbox / outbox health | Durability Monitor |
| Forensic event browser | Event Store |
| Activity feed and operator audit | Activity Timeline · Audit Log |
| Message routing visualization | Message Topology |
| System reflection — how a service is wired | Event Modeling · Topology |
| Step through a projection event-by-event | Projection Stepper |
| AI agent access — query + operate over MCP | MCP Integration |
Next steps
- Install CritterWatch — package install + infrastructure prereqs.
- Quick Start Guide — connect your first service in five minutes.
- Explore the UI — page-by-page reference once you're up and running.