Replaying historical data for a specific consumer group requires stopping all active consumer instances in that group and running the kafka-consumer-groups command with the --reset-offsets option. You can shift offsets back to a specific timestamp, the earliest offset, or by a relative offset count, using --dry-run to verify target positions before applying them with --execute. Replay is only possible if the required records still reside within the topic retention window, and downstream sinks must be prepared to handle duplicate records cleanly.
Step-by-step offset reset procedure
First, shut down every running consumer pod in the target group. If any consumer remains connected, the group coordinator marks the group as active and immediately rejects the administrative offset reset command with an error.
Next, execute a dry run specifying the desired target timestamp:
kafka-consumer-groups --bootstrap-server broker:9092 \ --group fraud-detection-service \ --reset-offsets \ --to-datetime 2026-03-30T00:00:00.000Z \ --topic transactions \ --dry-run
A review of the dry-run output confirms the planned changes:
- Inspect the output table to verify that the planned offset for each partition matches the expected starting position from yesterday.
- Re-run the command replacing --dry-run with --execute to commit the updated offsets directly to __consumer_offsets.
- Restart the consumer application pods. They will pick up from the newly committed offset positions and begin reprocessing historical records.
Retention boundaries and downstream side effects
Before attempting a replay, confirm that topic retention has not already purged the historical data. If retention.ms is configured for 24 hours, data older than a day has been deleted from disk, and resetting to an earlier timestamp will simply fall back to the earliest surviving offset.
In addition, replaying historical records sends events to downstream databases a second time. If the downstream target uses raw append operations, replaying will cause duplicate rows. Downstream sinks must use idempotent upserts or clear out the affected historical partitions before the replay commences.