Troubleshoot Kafka Connect Tasks and Inspect Offsets
Open a connector's details to inspect its Tasks and Offsets. Use task failures to find what stopped processing, then use offsets and lag to understand where the connector has reached.
Inspect connector and task states
The Tasks tab shows the raw state reported by Kafka Connect for the connector and for each task. The overall status in the list and summary card also considers the task states.
If the connector itself is Failed, Paused, Stopped, Restarting, or Unassigned, that state takes precedence over its tasks. For a connector reported as Running, Kafma applies these rules in order:
| Task states | Overall status |
|---|---|
| All tasks have failed | Failed |
| Some tasks have failed | Degraded |
| No failed tasks, but at least one is restarting | Restarting |
| No failed or restarting tasks, but at least one is paused | Paused |
| Every task is running | Running |
| Other task states | Unassigned |
This is why the Connector row can show Running while the summary card shows Failed: the connector is running, but all of its tasks have failed.
Read failure details
Expand a failed task to see its error, stack trace, and worker address. When Kafma recognizes a common failure, it adds a plain-language diagnosis and a suggested next step. The original trace remains available to inspect or copy.
For a sink connector that stops on a malformed record, restarting without fixing the cause can fail at the same record again. If a rebalance assigns that partition to another task, that task can encounter the same record and fail too, potentially leaving every task failed. Whether an error stops a task depends on the connector and its error-handling configuration; see Kafka Connect error handling.
Use Inspect in Console when the diagnosis offers it to open the affected topic and inspect its records. Otherwise, open the topic in the Console, or use the partition action in Offsets to inspect near the group's committed position. Check the producer's encoding, the connector's converters, and the failing payload before restarting. Restarting alone does not repair the record or its configuration.
The worker address identifies where the task ran. Full worker logs are on that worker; the trace shown in Kafma is the failure returned by Connect.
Restart failed tasks
The connector menu chooses the restart scope from its current state:
- If the connector is Failed or any task has failed, Restart Failed Tasks restarts only the failed parts, leaving running tasks alone. This can include the connector itself if it failed.
- Otherwise, Restart restarts the connector and all of its tasks.
Use the restart action beside a task to restart only that task. Fix the underlying error first, then refresh the details to check whether the task remains Running.
Restart actions are unavailable on a Read-Only connection.
Inspect source offsets
For a source connector, Offsets displays the source partition identifiers and offsets that Connect has committed. These fields come from the connector and its external source; they are not necessarily Kafka topic partitions or numeric Kafka offsets.
Viewing source offsets requires Kafka Connect 3.5 or later. A source that has not committed its first batch has no stored offsets to display.
Inspect sink positions and lag
For a sink connector, Offsets reads its Kafka consumer group instead of the Connect source-offset API. It shows:
| Column | Meaning |
|---|---|
| Reading From | Kafka topic and partition |
| Position | The consumer group's committed offset, normally the next record to read |
| Lag | The difference between the partition's end offset and its committed position |
| Task | The task currently assigned to the partition, when the assignment can be identified |
Sink positions and lag do not require Connect 3.5. A partition without a committed position cannot provide a reliable lag value. Paused connectors can accumulate lag while producers continue writing.
Use the Console action beside a partition to inspect it in Watch Group mode. This reads messages near the committed position without joining the consumer group or changing its offsets.
When sink details are unavailable
Kafma reads the sink's consumer group from the current Kafka connection. If Connect uses a different Kafka cluster, its consumer group and partition details are unavailable here. Configure the Connect entry under the Kafka connection it actually uses.
If the group has no current assignment, positions can still exist while task information is unavailable. Check whether the connector is stopped, rebalancing, or failing, and refresh after it settles.