Skip to content

Projections

The Projections view monitors all projections and event subscriptions registered in your Marten- or Polecat-based services. Each projection is tracked by its shard — a specific named partition of the projection's work.

CritterWatch Projections view — every projection shard across all services with health, lifecycle, progress vs. gap, and run mode

Where this lives now

The standalone Projections page was folded into the Event Store Explorer as its Operations tab; /projections redirects there. The grid and controls below are unchanged — this page documents that Operations view.

Projections Grid

The grid shows all known projection shards across all monitored services:

The grid is deliberately parsimonious with horizontal space — several lower-signal columns are folded into others as dots or muted subscripts rather than standing on their own.

ColumnDescription
AlertActive lag / staleness alert for this projection (critical or warning), if any
StateCritterWatch's interpreted projection state — Healthy / Catching-up / Stalled / Failing / Paused / Idle / Inline / Unknown — fused from staleness, gap, apply errors, and dead-letter events. A small liveness dot to its left shows how recently the shard reported in (node alive); the tag shows whether the projection itself is healthy.
ServiceWhich monitored service owns this projection (hidden when a single service is filtered)
NameProjection and shard identifier (e.g., TripSummary:All); the High Water Mark row is pinned first within each service. A muted subscript beneath it shows the implementing .NET type (for self-aggregating projections, the document type).
StoreWhich event store this projection belongs to — an engine icon (Marten / Polecat) plus the store name. Hover for Main DocumentStore registration or the ancillary store's interface name. Essential in multi-store apps.
TypeSingle Stream / Multi Stream / Subscription / Flat Table / Event Projection / Composite (neutral grey — a classification, not a status)
LifecycleAsync / Inline / Live (neutral grey — not a status)
NodeThe node currently executing the shard
Progress / GapFor continuous projections, the gap (events behind the high water mark) with a lag-trend arrow; during a rebuild, a progress bar. A muted subscript shows when the shard last advanced.
ModeThe shard's run mode with a running / paused / stopped icon; the assigned node renders as a muted subscript beneath it.

The Running State, Health State, Type, and Lifecycle filter dropdowns each show a per-option count of how many projections sit in each bucket, so you can see what's out there before filtering (the service scope comes from the page's service selector). A metrics header above the filters summarises the selected store: High-Water Mark, Projections (with a health-count pill), Max Lag, and Dead Letters.

Rows lead with a selection checkbox; the Pause Selected / Restart Selected / Rebuild Selected toolbar applies the lifecycle actions to every ticked shard at once (each shows the ticked count and confirms before acting). The same three actions are available per-row under Actions.

State Colors

  • Green (Healthy) — advancing, caught up, no errors
  • Yellow (Catching-up / Stalled) — behind the high water mark beyond the threshold, or no progress within the expected window
  • Red (Failing) — an apply error is latched, or the projection has dead-letter events
  • Gray (Paused / Idle) — paused by operator action, or registered but not currently advancing

Stall Detection

A projection is considered stalled if its sequence number has not advanced within a configurable time window (default: 5 minutes). Stalled projections receive a warning badge and can trigger alerts.

CritterWatch can be configured to automatically attempt projection restart on stall detection. See Alert System for configuration.

Projection Detail

Click a projection row to open the detail panel:

Sequence Chart

A time-series chart showing the projection's sequence number and the event store high water mark over the past hour. The gap between the lines represents lag. A widening gap indicates the projection is falling behind; converging lines indicate it is catching up.

Alert History

A timeline of all alerts raised for this projection:

  • Stall detected / resolved
  • Lag threshold exceeded / recovered
  • Restart triggered (automatic or manual)
  • Operator pause / restart / rebuild / rewind

Controls

Pause — stop the projection shard. Messages continue to be written to the event store, but this shard will not advance. Use when you need to investigate shard state or before making schema changes. Requires confirmation.

Restart — resume a paused projection shard from where it stopped. Use after resolving the issue that caused you to pause.

Rebuild — reset the projection to sequence 0 and rebuild the entire read model from scratch. This is destructive and can take a long time for large event stores. Requires explicit confirmation. A progress indicator shows estimated completion during the rebuild.

For a rebuild that spans multiple stores or tenants — or one long enough that you'll want per-cell tracking, retry, and cancel — start it from the Rebuilds page instead, which runs through the batch-orchestration engine rather than the direct command.

Rebuild works for Inline projections too, not just async ones. An Inline projection has no async daemon agent, so the console addresses its rebuild by name; it runs through a transient rebuild agent that replays the events and then stops. Because an Inline projection updates synchronously as events are appended, its read model is briefly wiped and repopulated during the rebuild and concurrent live writes can race the replay — so the confirmation for an Inline rebuild carries an extra advanced-operation warning. Prefer a quiet window.

Rewind — reset the projection to a specific point:

  • Rewind to beginning — equivalent to rebuild without clearing the read model first
  • Rewind to sequence — enter a specific event sequence number
  • Rewind to timestamp — enter a date/time to find the nearest sequence and rewind to it

Rebuild vs. Rewind

Rebuild clears the read model and rebuilds from scratch — suitable when the read model is corrupted or the projection logic has changed.

Rewind moves the projection's position marker back without clearing the read model — suitable when you need to reprocess events after a bug fix but the existing data is not invalid.

Multi-Tenant Projections

For multi-tenant services, each tenant has independent projection shards. The grid shows all tenant-specific shards with the tenant ID displayed alongside the shard name. Rebuild and rewind operations target a specific tenant's event store.

Free for read-only monitoring. A commercial license is required for administrative actions and the MCP server.