---
title: "Kafka committed offsets: enable.auto.commit and restart"
description: "A consumer auto-commits after reading three records, crashes, and restarts at offset 3. The Kafka committed offset, not the live position, is the resume point."
url: https://monedula.dev/kafka-simulator/scenarios/committing-offsets/
---

# Kafka committed offsets: enable.auto.commit and restart

Scenario 02.1.3 · Committing offsets. Consumer groups · Intermediate · about 3 min · Apache Kafka 4.3.

The committed offset is the resume point. Auto-commit saves it periodically; manual commit lets the app choose when.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=02.1.3

## What you start with

The committed offset is where a group resumes after a restart or rebalance, distinct from its live read position. This scenario shows enable.auto.commit periodically saving the position, then a crash-and-restart resuming from the committed offset instead of re-reading.

## Step by step

1. **Consumer ready · auto-commit on** (t+0.000s): Group g1 reads with enable.auto.commit=true. Watch the committed offset (the resume point), not just the live position. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.1.3&t=0)
2. **Read and committed up to 3** (t+1.600s): The consumer read O1-O3 (position 3) and auto-commit saved that as the committed offset (3). The committed offset - not the position - is what survives a restart. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.1.3&t=1)
3. **Consumer crashed** (t+2.400s): c1 crashed and stopped polling. Its committed offset (3) is held by the group coordinator, independent of the live member. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.1.3&t=2)
4. **Restarted · resumes at the committed offset** (t+3.100s): c1 restarted and resumed at the committed offset 3 - it does NOT re-read O1-O3. Manual commit uses the same mechanism but the app picks exactly when to save, trading re-processing after a crash against losing un-committed work. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.1.3&t=3)

## The takeaway

The committed offset is a durable bookmark, not the read position - commit timing is the lever between at-least-once and at-most-once, deciding how much is reprocessed or skipped after a failure.

## Configs in this scenario

- [`enable.auto.commit`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_enable.auto.commit): Whether the consumer commits its offsets in the background every auto.commit.interval.ms (default true); with it on, records processed between the last commit and a crash are read again.

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_enable.auto.commit)