Installation

Requirements

• .NET 9.0 or later
• PostgreSQL 14+ — used by Marten for the CritterWatch event store
• A Wolverine transport (RabbitMQ is recommended) for service-to-CritterWatch communication

NuGet Packages

CritterWatch ships as two NuGet packages:

Wolverine.CritterWatch

Install this in each monitored service — the applications you want CritterWatch to observe.

dotnet add package Wolverine.CritterWatch

This package contains:

• CritterWatchObserver — hooks into the Wolverine runtime and publishes telemetry
• All inbound command message types (pause listener, replay messages, etc.)
• All outbound event message types (service updates, health reports, etc.)

CritterWatch

Install this in your CritterWatch server — the dedicated application that runs the monitoring console.

dotnet add package CritterWatch

This package contains:

• Hosting extensions (AddCritterWatch, UseCritterWatch)
• Marten event store projections for service state
• Alert system, SignalR hub, HTTP API
• Embedded Vue SPA (served as embedded assembly resources)

Version Compatibility

CritterWatch	Wolverine	.NET	Marten
1.x	5.14+	9.0	8.20+

CritterWatch is built on the same JasperFx ecosystem it monitors. The Wolverine.CritterWatch package must be compatible with the version of Wolverine used in your monitored services.

Transport Requirements

CritterWatch communicates with monitored services over a Wolverine transport. RabbitMQ is the recommended transport for production use because it decouples the services from the CritterWatch server and supports reliable message delivery.

You can use any Wolverine-supported transport:

Transport	Package	Notes
RabbitMQ	WolverineFx.RabbitMQ	Recommended for production
Amazon SQS	WolverineFx.AmazonSqs	Demoed by the in-tree Trip3 sample family via LocalStack (#206). Watch for the 1 MiB message-body limit — the CritterWatch wire format applies brotli + lazy-fetch on this transport to stay under it (#204 / PR #205).
SQL Server	WolverineFx.SqlServer	Good for SQL Server shops
In-memory	(built-in)	Development/testing only

The CritterWatch server listens on a dedicated queue (conventionally named "critterwatch"). A single CritterWatch BFF can listen on multiple transports in parallel — the in-tree dev stack does exactly that to monitor Rabbit-based and SQS-based sample services in the same dashboard. Monitored services pick whichever transport they're already using.

PostgreSQL Setup

CritterWatch uses Marten to store service state as events. You need a PostgreSQL database accessible to the CritterWatch server. The Marten schema is automatically created on first run.

-- Create the database (CritterWatch will create the schema)
CREATE DATABASE critterwatch;

The recommended docker-compose.yml fragment:

postgres:
  image: postgres:16
  environment:
    POSTGRES_USER: postgres
    POSTGRES_PASSWORD: postgres
    POSTGRES_DB: critterwatch
  ports:
    - "5432:5432"

rabbitmq:
  image: rabbitmq:3-management
  ports:
    - "5672:5672"
    - "15672:15672"

Next Step

See the Quick Start Guide to connect your first service.