# TiCDC Checkpoint Lag

## Question

Is lag produced before ResolvedTS advances or between ResolvedTS and
CheckpointTS, and which upstream or downstream stage is blocked?

## Enter When

Use for changefeed checkpoint lag, ResolvedTS stagnation, sink delay, initial
scan, redo, region-cache/reconnect, barrier, DDL, or downstream ACK symptoms.

## First Batch

1. Compare ResolvedTS lag and CheckpointTS lag for the same changefeed.
2. Upstream branch: inspect capture/maintainer/dispatcher progress,
   region/cache/reconnect, initial scan, stale locks, congestion, or barrierTS.
3. Downstream branch: inspect sink errors/latency, DDL or large event,
   worker/partition skew, load balancer, Kafka ACK, or downstream capacity.

## Decision

ResolvedTS lag localizes the path upstream; stable ResolvedTS with growing
CheckpointTS lag localizes it downstream. Architecture-specific metric names
must be selected only after distinguishing old versus new TiCDC architecture.

## Strongest Alternative And Stop

Check one stage on the opposite side of the ResolvedTS/CheckpointTS boundary.
Stop after the blocked stage is localized. Never resume, remove, recreate, or
change a changefeed automatically.