Configuration Reference

Monitored Service Configuration

AddCritterWatchMonitoring()

Call this inside UseWolverine() in each service you want to monitor.

Simple form — URI and service name:

opts.AddCritterWatchMonitoring(
    "amqp://localhost",   // RabbitMQ URI (or other transport)
    "my-service-name"     // Unique service name
);

Full options form:

builder.Host.UseWolverine(opts =>
{
    opts.AddCritterWatchMonitoring(
        // URI of the queue CritterWatch listens on for telemetry
        critterWatchUri: new Uri("rabbitmq://critterwatch"),

        // URI of the queue this service listens on for incoming commands
        systemControlUri: new Uri("rabbitmq://trip-service-control"),

        // How this service exports metrics (default: Hybrid)
        metricsMode: WolverineMetricsMode.Hybrid
    );
});

^{snippet source | anchor}

Options Reference

Option	Default	Description
RabbitMqUri	—	URI of the RabbitMQ broker (or transport endpoint)
ServiceName	—	Unique identifier for this service in CritterWatch
Label	ServiceName	Display name shown in the UI
HeartbeatInterval	1 second	How often state snapshots are published
AgentHealthCheckInterval	60 seconds	How often agent health is actively checked

Service Name Must Be Unique

The ServiceName is used as the Marten event stream key. Two services with the same name will overwrite each other's state. Use a name that uniquely identifies the service across your entire deployment.

CritterWatch Server Configuration

AddCritterWatch()

builder.AddCritterWatch(options =>
{
    // PostgreSQL connection string for Marten event store
    options.ConnectionString =
        "Host=localhost;Database=critterwatch;Username=postgres;Password=postgres";

    // The route where the SignalR hub is mounted (default: /api/messages)
    options.SignalRRoute = "/api/messages";

    // Wolverine transport configuration (RabbitMQ, SQL Server, etc.)
    options.ConfigureWolverine = wolverineOpts =>
    {
        wolverineOpts.UseRabbitMq(new Uri("amqp://localhost"))
            .AutoProvision();
        wolverineOpts.ListenToRabbitQueue("critterwatch").Sequential();
    };
});

^{snippet source | anchor}

UseCritterWatch()

Maps all CritterWatch middleware into the ASP.NET Core pipeline:

app.UseCritterWatch();

// Or with a custom SignalR route:
app.UseCritterWatch(signalRRoute: "/my-hub");

UseCritterWatch() registers:

• Wolverine HTTP endpoints under /api/critterwatch/*
• SignalR hub at /api/messages (configurable)
• Static file serving for the embedded Vue SPA
• Client-side routing fallback for the SPA

Docker Compose

A complete docker-compose.yml for local development:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: critterwatch
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "5672:5672"    # AMQP
      - "15672:15672"  # Management UI
    environment:
      RABBITMQ_DEFAULT_USER: guest
      RABBITMQ_DEFAULT_PASS: guest

volumes:
  postgres_data:

Connection String Formats

PostgreSQL

Host=localhost;Port=5432;Database=critterwatch;Username=postgres;Password=postgres

For cloud providers:

Host=my-postgres.postgres.database.azure.com;Database=critterwatch;Username=app@my-postgres;Password=secret;SSL Mode=Require

RabbitMQ

amqp://guest:guest@localhost:5672/
amqps://user:pass@my-rabbit.cloud:5671/  # TLS

appsettings.json

The recommended approach for managing connection strings:

{
  "ConnectionStrings": {
    "critterwatch": "Host=localhost;Database=critterwatch;Username=postgres;Password=postgres",
    "rabbitmq": "amqp://localhost"
  }
}

builder.AddCritterWatch(
    builder.Configuration.GetConnectionString("critterwatch")!,
    opts =>
    {
        var rabbitUri = new Uri(
            builder.Configuration.GetConnectionString("rabbitmq")!);
        opts.UseRabbitMq(rabbitUri).AutoProvision();
        opts.ListenToRabbitQueue("critterwatch").Sequential();
    });

Alert Threshold Configuration

See Alert System for full documentation on configuring alert thresholds per service and message type.

Alert thresholds support three levels of specificity:

// Global defaults (apply to all services):
//   DeadLetterQueueWarningCount: 10
//   DeadLetterQueueCriticalCount: 100
//   ProjectionLagWarningSeconds: 30
//   ProjectionLagCriticalSeconds: 300
//   AgentUnhealthyWarningCount: 2
//   AgentUnhealthyCriticalCount: 5
//
// Service-level overrides (apply to all alerts for one service):
//   Configured in Settings > Alert Configuration > Service Thresholds
//
// Per-message-type overrides (most specific):
//   Configured in Settings > Alert Configuration > Message Type Thresholds

Thresholds cascade: message-type specific → service specific → global defaults.