--- title: Chronicle subscription recovery and replay editUrl: https://github.com/Cratis/Chronicle/edit/main/Documentation/subscriptions/recovery.mdx description: Locate a Chronicle subscription failure before replaying. Forwarding can add duplicate inbox events; consumer replay processes stored events again. lastUpdated: 2026-11-05T00:00:00.000Z --- Recover a Cratis Chronicle subscription by first checking whether the event reached the consumer's inbox. If it is there but the view is empty, investigate consumer processing; replaying source forwarding can add duplicate inbox events without fixing the consumer's failure. Check the source outbox, the target's `inbox-{sourceEventStore}` sequence, and the affected consumer observer in that order. The point where progress stops tells you which part of the flow needs attention. ## Fresh history and retained progress A fresh subscription identity with no saved observer progress starts at sequence number zero in the retained source outbox. It forwards matching historical events as well as later publications. If you created the subscription after publication, check whether it is still catching up before requesting a replay. The forwarding observer saves a checkpoint: the position it has reached in the source outbox. Disconnecting does not erase it. Reconnecting the same subscription identity can resume there and catch up on publications made while disconnected, rather than forwarding the whole history again. Removing and recreating a subscription is not a reliable way to restart delivery from zero. These behaviors concern retained source events. Neither subscribing nor replaying restores events that are no longer available in the source outbox. ## Choose which observer to replay | Intended effect | Observer to replay | Result | | --- | --- | --- | | Reprocess events already in a consumer inbox | The consumer reactor, projection, or reducer observing that inbox | Processes existing inbox rows again without itself forwarding source events | | Forward retained source publications again | The source outbox subscription observer for that consumer | Appends forwarded events to the consumer inbox again | Before either operation, review what the affected consumers do when processing an event again. Source-forwarding replay can append another inbox row for an event already delivered, with a new inbox sequence number. That row can trigger ordinary consumer processing and repeat external actions. Replaying the inbox consumer can also repeat its actions, even though it does not add another forwarded copy. Fix the cause of the failure before choosing a replay. For example, a missing pinned schema or an erased subject's blocked encryption key will still prevent a target append after replay. See [Explicit Event Store Subscriptions](/chronicle/subscriptions/explicit-subscriptions/) for generation pins and [Compliance and PII](/chronicle/subscriptions/compliance-and-pii/) for the erasure behavior. ## Resolve the exact subscription scope For source-forwarding replay, start with the consumer's stored subscription definition. Identify its subscription ID, source event store, target event store, and namespace. The current forwarding observer ID is the subscription ID followed by `->` and the target event-store name. That observer belongs to the source store's outbox in the relevant namespace, not to the consumer's inbox. Different consumers and namespaces have separate forwarding progress, so verify the full scope before requesting replay. Do not derive the scope by splitting an arbitrary observer name: subscription IDs can themselves contain separators. Runtime metadata naming a target store is not enough to establish which stored definition owns the observer. Older observers can have different IDs from those linked by the current definition. Recreating a definition does not establish that the current observer inherits an older checkpoint. If the definition is missing or the link to an observer is unclear, stop and inspect the stored definition and scoped observer. Do not guess a forwarding target from its name. If your own tooling adds subscription and consumer labels around the replay API, treat them as unverified information supplied by the operator. Only the producer event store, namespace, and outbox observer ID select the replay target. Labels neither verify that selection nor restrict which consumer receives the forwarded events. Before such tooling opens a connection, it must warn that replay can create duplicate inbox rows and repeat consumer side effects, then require explicit confirmation. Verify the stored definition against the supplied scope rather than relying on a label. Do not assume that administrative lookups are read-only on every storage provider. This procedure uses the existing observer replay behavior; it does not provide a subscription-specific recovery command. ## Confirm recovery Wait for the replay job to complete before assessing the result. A successful replay request means the request was accepted, not that processing has finished. Check the consumer inbox separately from its derived views: source-forwarding replay should produce inbox events, while consumer replay should reprocess events already there. ## See also - [Explicit Event Store Subscriptions](/chronicle/subscriptions/explicit-subscriptions/) - [Outbox and Inbox](/chronicle/subscriptions/outbox-inbox/) - [Observers](/chronicle/concepts/observers/)