When should I call Commit here versus letting the consuming step handle it?

Call Manage Offsets > Commit only when the Consume Events or On Event Trigger step is configured with the Manual commit strategy. With After each read or After loop, the platform commits automatically and calling Commit here is redundant.

Is resetting an offset reversible?

No. The change takes effect immediately. Events between the old and new offset will be re-read (reset backward) or skipped (reset forward). If you are unsure, read the current offset first and store it before resetting, so you can restore it if needed.

Can I use Manage Offsets with a consumer group that is actively processing events?

Yes, but coordinate carefully. Committing or resetting an offset while a consumer is mid-read can cause that consumer to skip or re-read events unexpectedly. Prefer managing offsets between polling cycles rather than concurrently with active consumption.

Manage Offsets reads, commits, or resets the position of a consumer group on a stream. Use it with the manual commit strategy to advance your offset only after confirming successful processing, or to reset the position when you need to replay events from an earlier point in the stream.

Overview

An offset records how far a consumer group has read into a stream. Manage Offsets gives you direct control over that position: commit to advance it, reset to move it backward or to a named anchor, or read to check where the group currently stands without making any changes. It works in concert with the Manual commit option in Consume Events and On Event Trigger — when that strategy is selected, the platform does not advance the offset automatically, and you call Manage Offsets to do so explicitly.

Screenshot: Manage Offsets action configuration panel

Input

Field	Type	Required	Description
Stream	String	Yes	The stream whose offsets you want to manage.
Consumer group	String	Yes	The consumer group whose offset is being read, committed, or reset.
Action	Enum	Yes	Commit — advances the offset to the latest read position; Reset — moves the offset to a specified position or named anchor; Read — returns the current offset without changing it.
Target offset	Number	Conditional	The absolute position to reset to. Required when Action is Reset and you are specifying an exact offset rather than a named anchor.
Reset to	Enum	Conditional	Named anchor for the reset position: Earliest (replay from the start of the stream) or Latest (skip to the next new event). Required when Action is Reset and no absolute offset is provided.

Output

All three actions return the offset state after the operation completes.

Field	Type	Description
offset	Number	The current offset for the consumer group after the action was applied.
consumerGroup	String	The consumer group whose offset was read or updated.

Notes

Only use Manage Offsets > Commit when the consuming step (Consume Events or On Event Trigger) is set to the Manual commit strategy. The other strategies commit automatically — calling Commit manually in those modes has no additional effect.
A missed commit leaves the offset at the last committed position; the next poll re-reads all events from that point. Make consumers idempotent to handle re-reads safely.
Resetting to Earliest replays all events from the beginning of the stream — use carefully in production, as it can re-trigger significant downstream work.
Resetting to Latest skips all accumulated events and starts fresh from the next new event; any events between the old offset and the tail of the stream are not processed.
Resetting to an absolute offset is useful for targeted replays after an incident — for example, reprocessing events from a specific point in time.

Resets are immediate and irreversible: Once a consumer group offset is reset, the position changes right away. Test replay scenarios with a non-production consumer group before running them against live streams.