Browse documentation

Reset Kafka Consumer Group Offsets

Resetting Kafka consumer group offsets changes the committed positions from which the group continues. Reset backward to reprocess retained records, or reset forward to skip records the application should no longer read.

Before you reset Kafka consumer group offsets

Stop every active consumer in the group. Kafma enables offset changes only when the group is Empty or Dead, preventing a running consumer from committing its in-memory position over the reset.

Review the impact before continuing:

  • Moving backward can repeat processing and duplicate external side effects.
  • Moving forward causes the group to skip records unless you reset backward before retention removes them.
  • Retention limits how far backward a reset can go.
  • Reset and delete operations are unavailable on read-only connections.

Choose topics and partitions

Open the group menu and select Reset Offsets. Apply the reset to every topic with committed offsets, one topic, or selected partitions within a topic.

When you select one topic, Kafma lists the partitions that have committed offsets for this group.

Use the narrowest scope that matches the recovery. Resetting all topics to fix one partition can reprocess or skip unrelated records.

Reset Kafka consumer group offsets dialog with topic scope and five reset strategies

Reset offsets to earliest, latest, or another position

StrategyNew committed position
EarliestThe earliest offset still retained in each selected partition
LatestThe current end of each selected partition
Specific OffsetThe entered absolute offset, limited to each partition's current available range
DatetimeThe first offset whose record timestamp is at or after the selected time, or the current end if no later record exists
Shift ByThe current committed offset plus or minus a relative amount, limited to the available range

Earliest means the beginning of the data Kafka still retains, not necessarily offset 0. Retention or record deletion may already have advanced the earliest available offset.

A specific offset applies the same requested number to each selected partition, but Kafma limits the result independently to that partition's current low and high offsets. Shift By moves each existing committed offset forward with a positive value or backward with a negative value. Partitions without a committed offset are not shifted.

Kafka auto.offset.reset vs resetting offsets

These controls solve different problems:

  • Kafma's Reset Offsets action directly writes new committed offsets for the consumer group.
  • The consumer's auto.offset.reset setting is used only when the consumer cannot find a valid committed offset for a partition.

Resetting to Earliest writes each selected partition's current earliest retained offset as its committed position. The consumer resumes from those offsets while they remain valid; auto.offset.reset is used only when no valid committed offset exists.

If saved offsets are deleted, the consumer applies auto.offset.reset when it receives the partitions again. earliest starts from the earliest retained offset, latest starts at the current end, and none fails instead of choosing a position.

Delete consumer group offsets for a topic

To remove saved positions instead of replacing them, open an inactive group's details and expand the topic. Select the delete action beside that topic, then confirm Delete offsets.

Kafma deletes the group's committed offsets for that topic. The Kafka topic, its messages, and the consumer group remain. Kafka rejects the operation if the group still has active consumers or is subscribed to that topic.

Deleting committed offsets for one topic from an inactive Kafka consumer group

Deleting topic offsets differs from deleting the entire group. Group deletion removes the group and all its committed offsets; topic offset deletion clears only the selected topic's saved positions.

Verify the new position

After the operation:

  1. Refresh the group details and confirm the committed offsets.
  2. Check total and per-partition lag.
  3. Restart the consumers.
  4. Confirm that committed positions advance in the expected direction.

Use Watch Group to inspect messages around the new committed position without changing it.

Next steps