Best tools to reset Kafka consumer group offsets

The tools that reset Kafka consumer group offsets are the kafka-consumer-groups.sh CLI (a dry run by default, --execute to apply), the Admin API’s alterConsumerGroupOffsets for scripted resets, the Kafka Streams application reset tool, and UIs such as Kpow, AKHQ, Kafbat UI and Conduktor Console. Every one of them needs the consumer group to be inactive first.

They differ on whether you can preview the change, how finely you can scope it, what they do when the group is still running, and whether anyone can see who did it afterwards. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option. What an offset is, and how lag is read from it, is covered in Kafka offsets, part of the complete Kafka guide.

Reset offsets with the native CLI: dry run, then execute

Stop every consumer in the group first. The Apache Kafka operations documentation says to “first make sure that the consumer instances are inactive”, and the Admin API rejects offset changes for a group with members. Confirm the group is empty:

kafka-consumer-groups.sh --bootstrap-server <broker:9092> \
  --describe --group <group> --state

The STATE column should read Empty. Before changing anything, export the current offsets so you can put them back:

kafka-consumer-groups.sh --bootstrap-server <broker:9092> \
  --group <group> --all-topics \
  --reset-offsets --to-current --export > offsets-before.csv

Then plan the reset. Without --execute the command only prints the plan, with a NEW-OFFSET per partition. --dry-run makes that explicit:

kafka-consumer-groups.sh --bootstrap-server <broker:9092> \
  --group <group> --topic <topic> \
  --reset-offsets --to-datetime 2026-09-22T09:00:00.000 --dry-run

Read every row. If it is what you intended, run the same command with --execute in place of --dry-run. If it goes wrong, the export restores the old positions:

kafka-consumer-groups.sh --bootstrap-server <broker:9092> \
  --group <group> --reset-offsets --from-file offsets-before.csv --execute

The scope is one group at a time, and one of --all-topics, --topic <topic>, or --topic <topic>:0,1,2 for specific partitions. The strategies are --to-earliest, --to-latest, --to-offset, --to-datetime, --by-duration, --shift-by (positive or negative), --to-current and --from-file. Out-of-range results are clamped to the partition’s available offsets, so shifting 15 past an end offset of 10 lands on 10.

A Kafka Streams application needs its own tool. kafka-streams-application-reset.sh resets the input topics and deletes the internal topics, and the application reset tool documentation warns it “makes irreversible changes”. Unlike kafka-consumer-groups.sh, it runs for real unless you pass --dry-run.

What to score an offset reset tool on

An offset reset rewrites where a consumer group will resume reading. Done right, it replays a window after a bad deploy or skips a backlog nobody needs. Done wrong, it silently drops data or reprocesses a topic from the beginning. Five criteria decide how likely each is with a given tool.

1. Can you preview the change?

A dry run that prints the new offset for every partition is the single most important safety feature. The CLI previews by default. The Streams reset tool does not, which catches people who assume it behaves like its sibling.

2. How finely can you scope it?

Group, topic and partition are the scopes that matter. Skipping one bad record needs a single partition, the case walked through in how to find and skip a poison pill. Replaying after a bad deploy usually needs one topic. A tool that only resets a whole group, or makes partition scope awkward, turns a small fix into a large one.

3. What happens when the group is still running?

Kafka refuses an offset change while the group has active members. The Admin API documentation for alterConsumerGroupOffsets states that “the group must be empty”, and adds that it “is not transactional so it may succeed for some partitions while fail for others”. As Derek Troy-West, our co-founder and CEO, puts it, that requirement is Kafka’s, and tools work with what Kafka allows. They differ on what they do about it: fail and make you retry, or schedule the change until the group empties.

4. Does it keep resets deliberate?

My rule is that production consumers use auto.offset.reset=latest, and any reset is a deliberate, manual operation. Setting earliest just in case is easy to forget, and the day a consumer group ID changes, even for an innocent reason like renaming a service, the group reprocesses everything from the beginning. A tool should make the reset an explicit act with a named target.

A reset is also not always the right tool. In one incident I covered in a talk on Kafka operational issues, a partition count increase plus auto.offset.reset=latest meant hundreds of messages per partition, across around a hundred partitions, were silently skipped. The system was real-time and could not stop processing, so instead of rewinding the group, a parallel consumer replayed the missed offsets, tens of thousands of messages, without interrupting live traffic.

5. Who is allowed to do it, and is it recorded?

A reset in production usually happens during an incident, under pressure. Tom Crowley, our founding engineer, described the typical path in 2021, a problem now covered in break-glass access with temporary policies: a VPN, a jumpbox, and “the right combination of bash commands against the Kafka cluster”, from a jumpbox that “generally has full access to the Kafka cluster” with “no audit log recording the actions being committed”. The better tools gate resets behind a role, can require approval, and log who reset which group to where. The best tools to control destructive Kafka operations applies the same question to deletes, truncation and config changes.

F1 The default that keeps resets deliberate /resources/kafka/

Use latest in production and make offset resets a deliberate, manual operation.

Chad Harris, Solutions Architect at Factor House

Offset reset tools compared

The table scores each tool on the five criteria in order. Managing offsets inside Kpow step by step, with a local environment you can run, is covered in manage Kafka consumer offsets with Kpow.

Tool	Preview	Scope	Strategies	When the group is running	Access control and audit	Source
kafka-consumer-groups.sh	Yes, dry run is the default, --execute applies	One group, all topics, a topic, or topic:partitions	Earliest, latest, offset, datetime, duration, shift-by, current, from file	Fails, you stop the consumers and rerun	Whoever holds CLI credentials, no audit	Apache Kafka docs
Admin API alterConsumerGroupOffsets	Only what your code prints	Any set of partitions you pass	Any offset you compute	Fails, “the group must be empty”, and may partially succeed	Your code’s responsibility	Apache Kafka Javadoc
kafka-streams-application-reset.sh	Only with --dry-run, it runs for real by default	One Streams application: input topics reset, internal topics deleted	Earliest by default, plus other positions	All instances must be stopped	Whoever holds CLI credentials, no audit	Apache Kafka docs
Kpow	Its docs do not describe a preview step. Scheduled resets can be cancelled before they run, and staged mutations add an approval	Whole group, host, topic or partition	Offset, timestamp, local datetime, clear to earliest, skip one offset	Scheduled, runs once the group is EMPTY, up to 15 minutes by default	GROUP_EDIT permission, staged mutations, temporary policies, audit log (Enterprise)	Kpow docs
AKHQ	The form shows each partition’s current, first and last offset before you submit	Per partition, in a form	Earliest, latest, timestamp or a typed offset per partition	Kafka rejects the change	UPDATE_OFFSET role, opt-in audit events to a Kafka topic	GitHub: tchiotludo/akhq
Kafbat UI	The form states the target, with no dry-run step in its reset API	A topic, optionally specific partitions	Earliest, latest, timestamp, offset	Refused unless the group is EMPTY or DEAD	RESET_OFFSETS permission, audit log to a topic or console	GitHub: kafbat/kafka-ui
Conduktor Console	Yes, a Preview step shows current and new offset per partition	All partitions, specific topics, or specific topic-partitions	Earliest, latest, offset, timestamp, shift-by	Must be inactive (Empty or Dead)	RBAC with a consumer group Reset permission, audit log	Conduktor’s documentation, Consumer groups and RBAC pages

How the options score

On preview, the CLI and Conduktor Console lead: both show the new offset for every partition before anything changes. AKHQ’s form shows current, first and last offsets per partition as you edit, which works as a preview. Kpow’s documentation does not describe a preview step, so a Kpow reset relies on scheduling, cancellation and approval rather than a dry-run table. That is a real gap next to the CLI.

On scope, Kpow is the most flexible, because it can reset from any dimension of the group’s topology: the whole group, one host’s assignments, a topic, or a single partition. The CLI and Conduktor both reach partition level. Kafbat UI works one topic at a time.

On strategies, the CLI has the longest list, including --by-duration, --from-file and negative --shift-by, and it is the only tool here with a built-in export and restore. Conduktor comes closest in a UI with shift-by.

On a running group, Kpow is the only tool here that schedules the reset and applies it the moment the group reaches EMPTY, so you can queue the change, scale the consumers down, and not race them. Everything else fails and waits for you to try again. Kpow also reads offsets for EMPTY groups directly from the AdminClient, so a group taken offline by a poison message can still be reset.

On access and audit, Kpow gives the most options: a GROUP_EDIT permission, staged mutations that put an administrator’s approval in front of the reset, temporary policies that grant GROUP_EDIT on one group for a fixed window, and an audit log of the request and the policies it was checked against. Conduktor, AKHQ and Kafbat UI all have role-based permissions and audit logs. The CLI and the Admin API have neither.

Each tool in detail

How Factor House approaches offset resets

Kpow is built around the idea that an offset reset should be quick to do correctly and hard to do by accident. The consumer group documentation covers the actions: reset by offset, timestamp or datetime at group, host, topic or partition level, clear to earliest, and skip one offset on a partition. Every group action is scheduled and runs once the group’s state is EMPTY, for up to 15 minutes by default (MUTATION_SCHEDULER_EXPIRES_MS), and you can watch or cancel it from the Mutations tab. Staged mutations add an approval step, temporary policies grant GROUP_EDIT on one group for a fixed window, and the audit log records each request with the user, the action and the policies it was checked against. In the live Kpow demo, open a consumer group’s topology and select the group, a topic or a partition to see the reset, clear and skip options at each scope. The Kpow product page covers the rest of the product.

If a reset is needed because consumers are falling behind, measure the lag first with one of the tools to monitor consumer lag. What is Kafka rebalancing? and Kafka consumers in production cover the causes a reset will not fix.

Kpow live demo

Preview an offset reset before you run it

Open the Kpow demo to see consumer group offsets by partition and how a reset is scoped, permissioned and logged.

Built for platform and data engineers running Kafka in production.

Try the Kpow demo→

FAQ

How do I reset a Kafka consumer group’s offsets?

Stop every consumer in the group, then run kafka-consumer-groups.sh --reset-offsets with a scope (--all-topics, --topic, or --topic <topic>:<partitions>) and a strategy such as --to-earliest or --to-datetime. Check the dry-run output, then rerun with --execute. Export the current offsets first with --to-current --export so you can restore them.

Can I reset offsets while consumers are running?

No. Kafka only accepts offset changes for a group with no active members. Kpow can schedule the reset so it runs the moment the group empties, and every other tool here makes you stop the consumers first and then run it.

What is the difference between auto.offset.reset and resetting offsets?

auto.offset.reset is a consumer setting that only applies when a group has no committed offset for a partition, such as a brand-new group. Resetting offsets changes the committed offsets of an existing group. Use latest for auto.offset.reset in production and treat resets as deliberate operations.

How do I reset offsets for a Kafka Streams application?

Use kafka-streams-application-reset.sh, not kafka-consumer-groups.sh, because it also deletes the application’s internal topics. Stop every instance, run it with --dry-run first, and delete the local state stores on each instance before restarting.

Related reading

• Kafka: the complete guide
• Kafka offsets
• Kafka consumer groups
• Kafka consumers in production
• What is Kafka rebalancing?