Best tools to monitor Kafka Connect connectors

Comparisons

Chad Harris·September 22, 2026·16 min read

Monitoring Kafka Connect means knowing, per task, whether each connector is moving data, and being told when one stops. The options are the Connect REST API with your own scripts, JMX metrics scraped into Prometheus and Grafana, the Strimzi operator’s KafkaConnector resources on Kubernetes, Amazon MSK Connect’s CloudWatch metrics, Confluent Control Center, and the Kafka UIs with a Connect view: Kpow, Kafbat UI, AKHQ and Lenses. 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 a Connect monitoring tool has to capture

Connect fails in ways a broker dashboard does not see. Six criteria decide whether a tool catches those failures, and every option is scored against them in this order.

Task state, not only connector state. The connector instance coordinates and the tasks move the data, so a connector can report RUNNING while its tasks have FAILED. The Kafka Connect topic page describes it as the gap between “the connector says RUNNING” and “the data is actually flowing correctly”. A tool that shows one status per connector hides exactly the failure you most need to see. When I asked “are my connectors healthy?” in a demo on 11 September, three connectors were not running, and the answer came from task state and task traces, not the connector list.

Per-task metrics, split by source and sink. State tells you a task died. Metrics tell you a task is alive but falling behind. For sink connectors the signal is the consumer side, how far the task’s consumer lags the topic, and for source connectors it is the poll rate. Apache Kafka exposes these per task over JMX, including sink-record-lag-max, source-record-poll-rate, offset-commit-completion-rate and the error counters total-record-errors and total-records-skipped (Connect monitoring reference). The consumer side of a sink connector is ordinary consumer lag, which the comparison of Kafka consumer lag monitoring tools scores in depth. One detail catches people out: the per-connector task counts such as connector-failed-task-count are reported by each worker, so a cluster-wide number has to be summed across workers.

Restarts, including restarting only what failed. Apache Kafka Connect does not restart failed tasks by itself. KIP-745 says so directly: “Kafka Connect does not do any of this out of the box.” Since Kafka 3.0 the REST API can restart a connector and only its failed tasks in one call, but the older call, which a lot of tooling still sends, restarts the connector instance and leaves failed tasks failed. The questions for a tool are whether it restarts tasks at all, whether it can do so automatically, and whether automatic restarts are rate-limited. That last one matters in an outage. When Tom Crowley, our founding engineer, added a limit to Kpow’s auto-restart, the default of 50 per one-minute interval meant 400 failed connectors would be restarted in eight batches over eight minutes rather than all at once against a Connect cluster that is already struggling.

Alerting on failed tasks. The alert that matters is simple: failed tasks above zero for a connector you care about. A tool either raises it, exports a metric something else can alert on, or leaves you to poll.

The cost of watching. A tool that polls the REST API makes calls per connector, and at hundreds of connectors that is real load on the workers. Derek Troy-West, our co-founder and CEO, looked at this when Kpow moved to a newer way of reading Connect: it went from one list call plus three calls per connector every minute, to exactly one call per minute. Ask any polling tool how it reads a large Connect cluster.

Multi-cluster Connect with access control. Most organisations run more than one Connect cluster, often a mix of self-managed workers and managed connectors. A platform team evaluating Kpow gave us a question list that captures the requirement well: stop application teams deleting connectors or seeing other teams’ connectors, tie those permissions to the company’s identity provider, show self-managed and managed connectors on the same page so users do not have to know the difference, and stay responsive with thousands of connectors across many Connect clusters.

The options, compared

Every cell below comes from the tool’s own documentation or source code. Where a capability does not appear in the tool’s own material, the cell says “not documented” rather than no.

Tool	Task-level state	Per-task metrics	Restarts	Auto-restart of failed tasks	Alerting	Multi-cluster and access control	Source
Connect REST API and scripts	Yes, every task’s state and trace from the status endpoint	No, metrics are JMX only	Yes, connector, failed tasks only, or a single task	Only if you script it	Only if you script it	One call per cluster, access control is whatever sits in front of the REST port	Apache Kafka Connect user guide
JMX exporter with Prometheus and Grafana	Yes, a status gauge per task in the official example mapping	Yes, the deepest of any option, every Connect MBean	No, read-only	No	Yes, through Alertmanager rules you write	Any number of clusters, access control is Grafana’s	JMX exporter Connect example
Strimzi KafkaConnector resources	Yes, the raw REST status map in each resource’s status	Task status panels in Strimzi’s example Grafana dashboard	Yes, by annotation, connector or single task	Yes, `spec.autoRestart` with increasing backoff capped at 60 minutes, unlimited by default	Through Prometheus	Kubernetes-only, access control is Kubernetes RBAC	Strimzi configuration reference
Amazon MSK Connect	Connector-level only	Per connector in CloudWatch, not per task	Connector-level, with a failed-tasks-only option on Connect 3.7 and later, no single-task restart	Not documented	Through CloudWatch alarms	Per AWS account and Region, access through IAM	MSK Connect restart docs
Confluent Control Center	Yes, running, degraded, failed and paused counts	Not documented in the pages checked	Yes, restart failed tasks, failed connector, or both	Not documented	The alert triggers page lists broker, cluster, consumer group and topic triggers, not Connect	Multiple Connect clusters, Confluent Platform scope	Confluent docs: Control Center, Connect and Alerts (text only)
Kpow	Yes, connector and task state side by side, with task stack traces	Connector and task state counts, exported to Prometheus, and connector metrics charts	Yes, connector, stop, pause, and individual tasks	Yes, by connector name or wildcard, rate-limited and audited	Exports Prometheus metrics for Alertmanager, and posts auto-restarts to Slack	Multiple Connect clusters per Kafka cluster (Enterprise), MSK Connect and Confluent Cloud managed connectors, per-action RBAC	Kpow Connect configuration docs
Kafbat UI	Yes, connector and task status	Not documented	Yes, but the Restart action restarts the connector instance only. Restart failed tasks loops per task	Not documented	Not documented	Multiple Connect clusters per Kafka cluster, free RBAC	Kafbat UI configuration docs
AKHQ	Yes, connector and task status	Not documented	Yes, connector restart is connector-only, plus per-task restart	Not documented	Not documented	A list of Connect clusters per connection, free RBAC	AKHQ configuration docs
Lenses	Yes, task health, metrics and stack traces	Yes, per its Connect docs	Yes, connector or individual task	Not documented	Yes, including Connector Failed and Connect Worker is down	Multiple Connect clusters, commercial	Lenses docs: Kafka Connect and Alert reference (text only)

Here is how the scores work out. For per-task metrics depth, the JMX exporter with Prometheus and Grafana beats every UI here, including Kpow, because it can expose every Connect MBean. For automatic recovery, Strimzi and Kpow are the only options with documented auto-restart, and they differ in style: Strimzi backs off per connector from immediate to hourly and retries indefinitely by default, while Kpow retries on a fixed window with a fleet-wide cap per interval. For alerting built into the tool, Lenses has Connect-specific alert rules and Kpow and Strimzi rely on Prometheus. For restarts, check what the button actually sends: in Kafbat UI and AKHQ source, the connector Restart action calls the old restart endpoint, which does not restart failed tasks. For mixed self-managed and managed Connect under one access model, Kpow covers the most ground here.

A note on Debezium UI. It still appears in older lists of Connect tools, but its repository is archived and states that the UI for Kafka Connect deployments is no longer developed (Debezium UI repository). For choosing between Debezium and other connectors, see Debezium vs Kafka Connect.

Kpow

factorhouse.io

46 out of 60 Total

Listed first because it is our product. Scores are unadjusted.

Type: Kafka UI and API
Auto-restart: Rate-limited, 50 connectors per interval
Multi-Connect and RBAC: Enterprise

Task-level state: 9 out of 10
Per-task metrics: 6 out of 10
Restarts: 7 out of 10
Auto-restart of failed tasks: 8 out of 10
Alerting: 6 out of 10
Multi-cluster and access control: 10 out of 10

What it is. Factor House’s management UI and API for Kafka, with Connect alongside topics, consumer groups and schemas.

State and metrics. Connector and task state side by side, with the stack trace of any failed task, and connector metrics charts over time. With PROMETHEUS_EGRESS enabled it exports Connect metrics per Connect cluster, including connect_connector_failed_total and connect_connector_task_failed_total (Kpow Prometheus integration). It does not replace the JMX exporter for deep per-task throughput metrics.

Restarts and alerting. Restart, pause, stop and delete connectors, and restart individual tasks. Auto-restart is set per connector name or wildcard with CONNECT_AUTO_RESTART: Kpow checks every minute, waits 10 minutes between attempts on the same connector by default, and caps restarts at 50 connectors per interval. Every automatic restart is written to the audit log as kpow_system and can be posted to Slack. Alerting on thresholds goes through Prometheus and Alertmanager.

Multi-cluster and access. Multiple Connect clusters per Kafka cluster, configured with CONNECT_RESOURCE_IDS, is an Enterprise feature. Kpow also works with Amazon MSK Connect and Confluent Cloud managed connectors. RBAC separates CONNECT_CREATE, CONNECT_ALTER_STATE (pause, stop, resume, restart), CONNECT_EDIT_CONFIG, CONNECT_DELETE and CONNECT_INSPECT, and resources can be matched by pattern, for example every connector whose name starts with a team prefix.

Where it wins and where it falls short. It leads on the combination: task-level diagnosis, rate-limited auto-restart and per-action access control across mixed Connect clusters in one place. It trails the JMX exporter on metric depth and Lenses on built-in alert rules, and multi-Connect and RBAC need the Enterprise licence, from $4,500 per cluster per year.

Source. Kpow Connect configuration, Kpow Connect management and Kpow authorization.

Compare Kpow vs Kafbat UI Kpow vs AKHQ Kpow vs Lenses.io Kpow vs Confluent Control Center

Strimzi KafkaConnector resources

strimzi.io

40 out of 60 Total

Type: Kubernetes operator
Auto-restart: spec.autoRestart, backoff to 60 minutes

Task-level state: 8 out of 10
Per-task metrics: 4 out of 10
Restarts: 9 out of 10
Auto-restart of failed tasks: 9 out of 10
Alerting: 5 out of 10
Multi-cluster and access control: 5 out of 10

What it is. On Kubernetes, Strimzi manages connectors as custom resources, and each resource’s status carries the connector’s REST status.

State and metrics. The status includes conditions and connectorStatus, “the connector status, as reported by the Kafka Connect REST API”. Strimzi’s example Grafana dashboard for Connect has panels for connector status, task status and tasks with issues.

Restarts and alerting. Manual restarts use annotations: strimzi.io/restart for the connector, with an option for failed tasks only, and strimzi.io/restart-task for one task. Automatic restarts are set with spec.autoRestart, which restarts immediately, then after 2, 6, 12, 20, 30, 42 and 56 minutes, then every 60 minutes, indefinitely unless maxRestarts is set (Strimzi configuration reference).

Multi-cluster and access. Kubernetes-only, scoped by namespace, with Kubernetes RBAC.

Where it wins and where it falls short. It beats Kpow on the backoff design for a single connector that keeps failing. It only covers Connect clusters that Strimzi runs, so managed connectors and workers outside Kubernetes are not in view.

Source. Strimzi configuration reference and Strimzi deployment guide, restarting connectors.

Lenses

lenses.io

40 out of 60 Total

Type: Commercial Kafka management
Connect alerts: Connector Failed, Connect Worker is down

Task-level state: 9 out of 10
Per-task metrics: 7 out of 10
Restarts: 7 out of 10
Auto-restart of failed tasks: 1 out of 10
Alerting: 10 out of 10
Multi-cluster and access control: 6 out of 10

What it is. A commercial Kafka management product with a Connect section.

State and metrics. Lenses’ Connect documentation describes inspecting “task health, metrics, and stack traces”.

Restarts and alerting. Restart a connector or an individual task. Its alert reference includes a Connector Failed alert, raised when a connector or any of its workers is down, and Connect Worker is down. Its docs describe no auto-restart.

Multi-cluster and access. Multiple Connect clusters are supported, under Lenses’ commercial licensing.

Where it wins and where it falls short. It beats Kpow on built-in Connect alert rules, and its docs describe no auto-restart.

Source. Lenses documentation: Integrating data with Kafka Connect, and Alert reference (named in text, not linked).

Compare Kpow vs Lenses.io AKHQ vs Lenses Kafbat UI vs Lenses Confluent Control Center vs Lenses Lenses review

JMX exporter with Prometheus and Grafana

github.com/prometheus/jmx_exporter

30 out of 60 Total

Type: Metrics exporter and dashboards
Actions: Read-only

Task-level state: 8 out of 10
Per-task metrics: 10 out of 10
Restarts: 0 out of 10
Auto-restart of failed tasks: 0 out of 10
Alerting: 6 out of 10
Multi-cluster and access control: 6 out of 10

What it is. The Prometheus JMX exporter runs alongside each worker and publishes Connect’s MBeans as Prometheus metrics, graphed in Grafana.

State and metrics. The exporter’s official Connect example maps the string status attribute to a gauge per connector and task, and maps the task error, sink and source metrics numerically. This is the deepest per-task metric coverage available.

Restarts and alerting. Read-only, so no restarts. Alerting is Alertmanager rules you write, such as failed tasks above zero.

Multi-cluster and access. Scrape as many Connect clusters as you like. Access control is Grafana’s.

Where it wins and where it falls short. It beats Kpow on per-task metric depth, and it is what most Kubernetes platform teams already run. It cannot act, so a failed task alerts someone who then goes to another tool to restart it. For the brokers underneath Connect, see Kafka broker health tools. Our guide to Kafka alerting with Prometheus and Alertmanager covers the alerting side.

Source. Prometheus JMX exporter and its Kafka Connect example configuration.

The Connect REST API and scripts

kafka.apache.org

29 out of 60 Total

Type: Worker REST API
Ships with: Apache Kafka

Task-level state: 9 out of 10
Per-task metrics: 0 out of 10
Restarts: 9 out of 10
Auto-restart of failed tasks: 4 out of 10
Alerting: 4 out of 10
Multi-cluster and access control: 3 out of 10

What it is. The API every Connect worker exposes, and the ground truth every other tool on this page reads from.

State and metrics. GET /connectors/<name>/status returns the connector state, every task’s state and worker, and a trace for anything that failed. It carries no throughput or lag metrics, which live in JMX.

Restarts and alerting. POST /connectors/<name>/restart?includeTasks=true&onlyFailed=true restarts the connector and only its failed tasks, and POST /connectors/<name>/tasks/<id>/restart restarts one task. Anything automatic or alerting is a script you write and run.

Multi-cluster and access. One call per Connect cluster. The REST port has no roles of its own beyond what you put in front of it.

Where it wins and where it falls short. It is free, exact and scriptable, and every diagnosis of a failed connector starts from it. It falls short as a monitoring system because nothing watches it unless you build the watcher.

Source. Apache Kafka Connect user guide, REST API.

Kafbat UI

github.com/kafbat/kafka-ui

24 out of 60 Total

Type: Open source Kafka UI
License: Apache 2.0

Task-level state: 8 out of 10
Per-task metrics: 1 out of 10
Restarts: 6 out of 10
Auto-restart of failed tasks: 1 out of 10
Alerting: 1 out of 10
Multi-cluster and access control: 7 out of 10

What it is. An open source web UI for Apache Kafka under Apache 2.0, with a Connect view.

State and metrics. Connector and task status. Its docs describe no per-task metrics.

Restarts and alerting. Its API offers restart, restart all tasks, restart failed tasks, pause, resume and stop. In its source, the Restart action restarts the connector instance only, and restart failed tasks is implemented by restarting each failed task in turn. No auto-restart or alerting is documented.

Multi-cluster and access. Multiple Connect clusters per Kafka cluster, and free RBAC.

Where it wins and where it falls short. It is free with RBAC included, and it shows state and offers actions without watching for failures itself.

Source. Kafbat UI configuration docs and the Kafbat UI repository.

Compare Kpow vs Kafbat UI AKHQ vs Kafbat UI Kafbat UI vs Lenses Kafbat UI review

Confluent Control Center

Confluent Platform

23 out of 60 Total

Type: Management UI
Scope: Confluent Platform

Task-level state: 6 out of 10
Per-task metrics: 1 out of 10
Restarts: 8 out of 10
Auto-restart of failed tasks: 1 out of 10
Alerting: 2 out of 10
Multi-cluster and access control: 5 out of 10

What it is. Confluent Platform’s management UI, with a Connect section.

State and metrics. Confluent’s documentation says the Connect page shows “the total number of running, degraded, failed, and paused connectors”, and that it manages connectors for multiple Connect clusters.

Restarts and alerting. It offers Restart Failed Tasks, Restart Failed Connector and Restart Failed Connector And Tasks. Its alert triggers page lists broker, cluster, consumer group and topic components, and no Connect trigger.

Multi-cluster and access. Multiple Connect clusters within Confluent Platform.

Where it wins and where it falls short. Its restart options match the modern API clearly, and it is licensed as part of Confluent Platform and scoped to it.

Source. Confluent documentation: Control Center, Manage Kafka Connect, and Alert Triggers (named in text, not linked).

Compare Kpow vs Confluent Control Center AKHQ vs Confluent Control Center Confluent Control Center vs Kafbat UI Confluent Control Center review

AKHQ

akhq.io

23 out of 60 Total

Type: Open source Kafka UI
License: Apache 2.0

Task-level state: 8 out of 10
Per-task metrics: 1 out of 10
Restarts: 5 out of 10
Auto-restart of failed tasks: 1 out of 10
Alerting: 1 out of 10
Multi-cluster and access control: 7 out of 10

What it is. An open source web UI for Apache Kafka under Apache 2.0, with Connect support.

State and metrics. Connector and task status. No per-task metrics documented.

Restarts and alerting. Its connector restart sends the plain restart call, which restarts the connector instance only, and it can restart individual tasks. No auto-restart or alerting documented.

Multi-cluster and access. A list of Connect clusters per Kafka connection, and free RBAC.

Where it wins and where it falls short. It is free and simple, with the same limitation as Kafbat UI: it shows state but does not watch it.

Source. AKHQ configuration docs and the AKHQ repository.

Compare Kpow vs AKHQ AKHQ vs Kafbat UI AKHQ vs Lenses AKHQ review

Amazon MSK Connect

aws.amazon.com/msk

22 out of 60 Total

Type: Managed Kafka Connect
Metrics: CloudWatch, per connector

Task-level state: 2 out of 10
Per-task metrics: 4 out of 10
Restarts: 4 out of 10
Auto-restart of failed tasks: 1 out of 10
Alerting: 6 out of 10
Multi-cluster and access control: 5 out of 10

What it is. AWS’s managed Kafka Connect, monitored through CloudWatch.

State and metrics. CloudWatch metrics are published per connector, including ErroredTaskCount and RunningTaskCount, with no per-task breakdown (MSK Connect monitoring).

Restarts and alerting. AWS’s restart documentation is explicit: “You cannot select specific individual tasks to restart.” Restarting only failed tasks needs Connect 3.7 or later, and a restart can report complete even if a task fails again afterwards. Alerting is CloudWatch alarms.

Multi-cluster and access. Per account and Region, with IAM.

Where it wins and where it falls short. You have no workers to run, but the monitoring and restart controls are coarser than on self-managed Connect.

Source. MSK Connect restart documentation.

Auto-restart, alerting and multi-cluster in practice

The three features that decide most evaluations interact, and it helps to see how.

Auto-restart fixes transient failures and hides persistent ones. A connector that fails because the database blipped comes back on the next attempt. A connector that fails because the target system does not support something it needs fails on every attempt, forever, and a restart loop turns one alert into many. In the 11 September demo, two connectors were failing because the catalog they wrote to did not support an endpoint the connector used, and a third because its Postgres database was refusing connections. None of the three would have been fixed by any number of restarts. That is why rate limits and backoff matter as much as the restart itself, and why a restart should be logged where people will see it. Kpow’s docs are direct about the boundary: a connector failing more often than the restart window “may require manual intervention”.

Alerting should key on failed tasks, per connector. An alert on connector state alone misses the RUNNING-with-failed-tasks case, and a cluster-wide count hides which connector broke. Whatever exports the metric, the rule is failed tasks above zero for a named connector, routed to the team that owns it.

Multi-cluster is where the access model gets tested. Once several teams share Connect clusters, the questions from that platform team’s list come up in the first week: who can restart, who can edit config, who can delete, and can a team see only its own connectors. Tools that treat restart and delete as one permission force a choice between too much access and too many tickets, which is the wider subject of the Kafka RBAC tools comparison.

How Factor House approaches it

Kpow is built to be the one place a platform team watches every Connect cluster it runs, self-managed or managed. The Connect view shows connector and task state together, opens any failed task’s stack trace, and restarts, pauses or stops connectors and individual tasks, with sensitive config values redacted (Kpow docs, Kafka Connect management). Auto-restart covers transient failures with a per-connector window and a fleet-wide cap, writes each attempt to the audit log and can post it to Slack. Connect metrics export to Prometheus for alerting. RBAC is per action and per resource pattern, so application teams can restart their own connectors without being able to delete anyone’s.

The test worth running in a Kpow demo is the one that separates the tools in the table: look at a connector that reports RUNNING and check whether every task under it is too, then open a failed task’s trace and restart just that task from the same screen.

What auto-restart cannot do is fix a failure outside Connect. The diagnosis for that case, including the demo above in full, is in how to diagnose and fix a failed Kafka Connect connector.

Product demo · 2 min

Apache Kafka Connect monitoring & task management: Kpow demo

Chad Harris walks through monitoring and managing Kafka Connect in Kpow: connector and task state at a glance, historical health charts, deploying new connector instances from the UI, and filtering to bulk-restart a subset of tasks.

Kpow live demo

Monitor Kafka Connect in a live UI

Open the Kpow demo to see connectors and their tasks across Connect clusters, including a running connector with a failed task.

Built for platform and data engineers running Kafka in production.

Try the Kpow demo

FAQ

How do I monitor Kafka Connect connectors?

Watch task state, not only connector state, through the REST status endpoint or a tool that reads it, and scrape per-task JMX metrics for lag, poll rate and error counts. Alert when failed tasks are above zero for any connector.

Does Kafka Connect restart failed tasks automatically?

No. Apache Kafka Connect leaves failed tasks FAILED. Strimzi’s spec.autoRestart and Kpow’s CONNECT_AUTO_RESTART restart them automatically, or you can script POST /connectors/<name>/restart?includeTasks=true&onlyFailed=true.

What metrics should I alert on for Kafka Connect?

Failed tasks per connector first. For sink connectors add consumer lag on the connector’s group, such as sink-record-lag-max, and for source connectors the poll rate, source-record-poll-rate. Add the error counters total-record-errors and total-records-skipped if you tolerate errors.

What is the best free tool to monitor Kafka Connect?

The JMX exporter with Prometheus and Grafana for metrics and alerting, paired with the REST API or a free UI such as Kafbat UI or AKHQ for state and restarts. Kpow Community Edition is free for up to three clusters and includes the Connect view, task restarts and stack traces.

More on running Connect and the rest of the platform is in the complete Kafka guide.