---
title: Operate and recover Chronicle observers
editUrl: https://github.com/Cratis/Chronicle/edit/main/Documentation/operations/index.mdx
description: Diagnose stopped Chronicle observers, choose a recovery that preserves or rebuilds state, and verify that event processing and output recover.
lastUpdated: 2026-11-05T00:00:00.000Z
---

**Operate a running Chronicle**

  Use Cratis Chronicle's observer state, failed-partition records and jobs to
  find why processing stopped, choose a recovery and check the resulting output.
  Start here when a read model goes stale, a reactor stops doing its work or an
  observer alert fires.

## The operator journey

An observer processes events for a projection, reducer or reactor. A failed partition holds back part of that work; it does not necessarily stop the whole observer. Diagnose the affected scope before choosing how much history to process again.

1. Monitor the [health endpoint](/chronicle/hosting/configuration/health-endpoint/) and configure [alerts on observer failures](/chronicle/hosting/alerting-on-observer-failures/) so you can investigate before a user reports stale output.
2. Follow [Diagnostics](/chronicle/operations/diagnostics/) to find the observer and partition in the correct event store and namespace. Read the exception and failing event sequence number, then check whether a recovery job is already running.
3. Use [Recovering from failures](/chronicle/operations/recovering-from-failures/) to choose between preserving the existing state with a retry and rebuilding it with a replay. Clearing quarantine can start processing again, so fix the cause and account for repeated side effects before releasing it.
4. Follow [Recover a failed partition](/chronicle/operations/recover-a-failed-partition/) to carry out the recovery through the Cratis CLI runbook and verify both processing progress and application output.

Chronicle automatically retries failed partitions with backoff, waiting longer between attempts. Intervene when the retry budget is exhausted or when the cause needs a code, data or dependency fix. A successful recovery request is only the start: the job and resulting output still need checking.

## Continue

  [Troubleshooting](/chronicle/troubleshooting/)

    Start from a symptom in your application.
  
  [Workbench](/chronicle/workbench/)

    Inspect runtime state and choose recovery actions in a browser.
  
  [Cratis CLI](/cli/)

    Find the command syntax and options for diagnosis and recovery.
  
  [Jobs](/chronicle/jobs/)

    See and control the background work the kernel runs.
  
  [Hosting](/chronicle/hosting/)

    Configure, deploy and alert on Chronicle.