Best tools to monitor Kafka Connect connectors
ComparisonsMonitoring 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.
At a glance
Nine options are scored here on this page's six weighted criteria, 80 points in all. The rubric is weighted: Multi-cluster and access control counts three times, and Task-level state, Per-task metrics, Restarts, Auto-restart of failed tasks and Alerting count once. The five listed first, of nine, each out of 80: Kpow 66, which takes its best score on Multi-cluster and access control (10 out of 10) and its lowest on Per-task metrics (6 out of 10); Lenses 52; Strimzi KafkaConnector resources 50; JMX exporter with Prometheus and Grafana 42; Kafbat UI 38, License: Apache 2.0.
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 Chad Harris 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, Factor House’s 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, Factor House’s 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 Factor House 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.
| Rank | Tool | Task-level state | Per-task metrics | Restarts | Auto-restart of failed tasks | Alerting | Multi-cluster and access control | Source |
|---|---|---|---|---|---|---|---|---|
| 1 | 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 |
| 2 | 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 |
| 3 | 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) |
| 4 | 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 |
| 5 | 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 |
| 6 | 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 |
| 7 | 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) |
| 8 | 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 |
| 9 | 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 |
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.
Rank 1 Kpow
66 out of 80 Total
Try Kpow in the live demo No signup needed.
- 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 ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
Why these scores for Kpow
- Task-level state 9 out of 10
- Connector and task state sit side by side, with task stack traces.
- Per-task metrics 6 out of 10
- It exports state counts to Prometheus and charts connector metrics, but it does not replace the JMX exporter for deep per-task metrics, so JMX and Lenses score higher.
- Restarts 7 out of 10
- It restarts the connector, stops it, pauses it, and restarts individual tasks, and the page does not name a failed-tasks-only restart.
- Auto-restart of failed tasks 8 out of 10
- It auto-restarts by name or wildcard, rate-limited and audited, one of two documented auto-restarts. Strimzi’s section says it beats Kpow on backoff design, so Strimzi scores higher.
- Alerting 6 out of 10
- It exports Prometheus metrics for Alertmanager and posts auto-restarts to Slack, and it trails Lenses on built-in alert rules.
- Multi-cluster and access control 10 out of 10
- The page’s summary says “For mixed self-managed and managed Connect under one access model, Kpow covers the most ground here”, and RBAC is per action.
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.
Staying patched. Kpow’s release notes name the CVEs each release remediates, and the 96.4 image built on 5 August 2026 bundles 311 dependencies of which one carries a high or critical advisory, none of them published before that release. That is not a claim to patch faster than a community project: Kpow’s own dependency remediation has run from 14 to 128 days, and the current image still ships CVE-2026-75595 in netty, a 9.1 critical public since 19 August 2026, unpatched. What a licence buys here is not a different deployment model, because Kpow is self-hosted too. It is a company contracted to ship the fix. Every dependency figure on this page was read on 24 September 2026 from the published artefacts and from nvd.nist.gov.
Compare Kpow vs Kafbat UIKpow vs AKHQKpow vs Lenses.ioKpow vs Confluent Control Center
Rank 2 Lenses
lenses.io
52 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
Why these scores for Lenses
- Task-level state 9 out of 10
- It shows task health, metrics and stack traces.
- Per-task metrics 7 out of 10
- Its Connect docs describe per-task metrics, below the JMX exporter, which the page’s summary says beats every UI.
- Restarts 7 out of 10
- Restarts cover a connector or an individual task, with no failed-tasks-only option named.
- Auto-restart of failed tasks 1 out of 10
- Auto-restart is not documented, and its docs describe none.
- Alerting 10 out of 10
- The page’s summary makes it the only tool here with Connect-specific alert rules built in, and it beats Kpow on built-in Connect alert rules.
- Multi-cluster and access control 6 out of 10
- It covers multiple Connect clusters and is commercial, while the page names no managed connectors or access model detail.
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.
Compare Kpow vs Lenses.ioAKHQ vs LensesKafbat UI vs LensesConfluent Control Center vs LensesLenses review
Rank 3 Strimzi KafkaConnector resources
50 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for Strimzi KafkaConnector resources
- Task-level state 8 out of 10
- Each resource’s status carries the raw REST status map.
- Per-task metrics 4 out of 10
- The example Grafana dashboard has task status panels, which show state rather than throughput or lag.
- Restarts 9 out of 10
- It restarts by annotation, either the connector or a single task, with an option for failed tasks only.
- Auto-restart of failed tasks 9 out of 10
- The page’s summary makes it one of only two options with documented auto-restart, and it beats Kpow on the backoff design for a single connector that keeps failing.
- Alerting 5 out of 10
- Alerting relies on Prometheus, while Lenses has built-in Connect rules.
- Multi-cluster and access control 5 out of 10
- It is Kubernetes-only, with access control by Kubernetes RBAC, so managed connectors and workers outside Kubernetes are not in view.
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.
Staying patched. Strimzi is community-maintained under the CNCF and it answers the patching question better than most vendors do. Thirty-eight releases in two years, six published CVEs, each with a coordinated-disclosure advisory, and on the last three batches the fixed release shipped the same day the advisory was published: 0.49.1 in December 2025, 0.50.1 in February 2026 and 1.0.1 in June 2026. Open source is not the risk here. The absence of a contract is, and Strimzi shows how little that has cost so far.
Rank 4 JMX exporter with Prometheus and Grafana
42 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
Why these scores for JMX exporter with Prometheus and Grafana
- Task-level state 8 out of 10
- The official example mapping gives a status gauge per task.
- Per-task metrics 10 out of 10
- It exposes every Connect MBean, the deepest of any option, and the page’s summary says it beats every UI here, including Kpow.
- Restarts 0 out of 10
- It is read-only, so it cannot act.
- Auto-restart of failed tasks 0 out of 10
- It has no auto-restart.
- Alerting 6 out of 10
- Alerting comes through Alertmanager rules you write.
- Multi-cluster and access control 6 out of 10
- Access control is Grafana’s, across any number of clusters.
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. The guide to Kafka alerting with Prometheus and Alertmanager covers the alerting side.
Source. Prometheus JMX exporter and its Kafka Connect example configuration.
Staying patched. The Prometheus JMX Exporter is Apache-2.0 with a published security policy, six releases in two years and no CVE filed against its own code. It runs as an agent inside the broker, so its version is part of the broker’s attack surface rather than beside it.
Rank 5 Kafbat UI
38 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
Why these scores for Kafbat UI
- Task-level state 8 out of 10
- Connector and task status are both shown.
- Per-task metrics 1 out of 10
- Per-task metrics are not documented, and its docs describe none.
- Restarts 6 out of 10
- Its Restart action restarts the connector instance only, and restart failed tasks loops per task, so failed tasks can be restarted but not by the main button.
- Auto-restart of failed tasks 1 out of 10
- It has no documented auto-restart.
- Alerting 1 out of 10
- Alerting is not documented, and it shows state without watching for failures itself.
- Multi-cluster and access control 7 out of 10
- Multiple Connect clusters per Kafka cluster are covered with free RBAC, and no managed connectors are named.
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.
Staying patched. Kafbat UI released v1.5.0 in April 2026 and has not shipped since. In the 157 days since, at least 20 high or critical advisories have been published against libraries that release bundles, including the same netty critical CVE-2026-75595 that the current Kpow image carries. Only 150 of its 266 bundled jars resolved to a Maven coordinate, so that count is a floor and the state of the release itself is unmeasured. Kafbat does publish a security policy, which AKHQ and Kafdrop do not, and the one CVE filed against its own code, CVE-2025-49127, was already fixed in the release that preceded the advisory. Six releases in two years.
Compare Kpow vs Kafbat UIAKHQ vs Kafbat UIKafbat UI vs LensesKafbat UI review
Rank 6 AKHQ
37 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
Why these scores for AKHQ
- Task-level state 8 out of 10
- It lists connector and task status.
- Per-task metrics 1 out of 10
- Per-task metrics are not documented.
- Restarts 5 out of 10
- Its connector restart is connector-only, plus a per-task restart, and no failed-tasks-only option is named.
- Auto-restart of failed tasks 1 out of 10
- Auto-restart does not appear in its docs.
- Alerting 1 out of 10
- Alerting is not documented, and it shows state but does not watch it.
- Multi-cluster and access control 7 out of 10
- A list of Connect clusters per connection comes with free RBAC, and no managed connectors are named.
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.
Staying patched. AKHQ has no CVE filed against its own code, and that is the wrong number to plan against. Release 0.28.0, cut on 6 August 2026, bundles 270 libraries and 18 of them carry a high or critical advisory. Sixteen were already public, with fixed versions already on Maven Central, on the day it shipped, and five are netty advisories Kpow had remediated three weeks earlier in 96.2: CVE-2026-44249, CVE-2026-45416, CVE-2026-45674, CVE-2026-47691 and CVE-2026-50010. The oldest has been open 108 days. That is exposure and remediation latency rather than a working attack, and every figure resolves against the published jar and nvd.nist.gov. Four releases in two years, and no security policy at any path GitHub reads.
Compare Kpow vs AKHQAKHQ vs Kafbat UIAKHQ vs LensesAKHQ review
Rank 7 The Connect REST API and scripts
35 out of 80 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 weight, this criterion counts 3 times toward the total
- 3 out of 10
Why these scores for The Connect REST API and scripts
- Task-level state 9 out of 10
- Its status endpoint returns every task’s state and trace, the ground truth every other tool reads from.
- Per-task metrics 0 out of 10
- Metrics are JMX only, so it carries no throughput or lag metrics of its own.
- Restarts 9 out of 10
- It restarts a connector, the failed tasks only, or a single task, which is the full modern restart API.
- Auto-restart of failed tasks 4 out of 10
- Auto-restart happens only if you script it, because anything automatic is a script you write and run.
- Alerting 4 out of 10
- Alerting happens only if you script it, and nothing watches it unless you build the watcher.
- Multi-cluster and access control 3 out of 10
- One call reaches one cluster, and the REST port has no roles beyond what you put in front of it.
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.
Confluent Control Center
Confluent Platform
33 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for Confluent Control Center
- Task-level state 6 out of 10
- Running, degraded, failed and paused counts are connector counts rather than a per-task view.
- Per-task metrics 1 out of 10
- Per-task metrics are not documented in the pages checked.
- Restarts 8 out of 10
- It restarts failed tasks, the failed connector, or both, and its restart options match the modern API clearly. No single-task restart is named.
- Auto-restart of failed tasks 1 out of 10
- No auto-restart is documented.
- Alerting 2 out of 10
- Its alert triggers cover broker, cluster, consumer group and topic, not Connect.
- Multi-cluster and access control 5 out of 10
- Multiple Connect clusters are covered within Confluent Platform scope, and the page names no access model.
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.
Compare Kpow vs Confluent Control CenterAKHQ vs Confluent Control CenterConfluent Control Center vs Kafbat UIConfluent Control Center review
Amazon MSK Connect
32 out of 80 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 ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for Amazon MSK Connect
- Task-level state 2 out of 10
- State is reported at connector level only.
- Per-task metrics 4 out of 10
- CloudWatch carries metrics per connector, not per task, including ErroredTaskCount and RunningTaskCount.
- Restarts 4 out of 10
- Restarts are connector-level, failed-tasks-only on Connect 3.7 and later, with no single-task restart, and AWS says “You cannot select specific individual tasks to restart.”
- Auto-restart of failed tasks 1 out of 10
- Auto-restart is not documented.
- Alerting 6 out of 10
- Alerting runs through CloudWatch alarms, a threshold on a metric you pick.
- Multi-cluster and access control 5 out of 10
- Scope is per AWS account and Region, with access through IAM and no mixed view of other Connect clusters.
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
Kafka Connect monitoring and tasks: Kpow demo
Chad Harris walks through Kafka Connect in Kpow: connector and task state at a glance, historical health charts, deploying connectors from the UI, and bulk-restarting a subset of tasks.
Kpow live demo
Monitor Kafka Connect in a live UI
Open the Kpow demo, switch the cluster picker from MSK Secondary to MSK Primary, then open Connect. Connector state and task state are listed separately, so a failed task under a running connector shows up.
Built for platform and data engineers running Kafka in production.
Try the Kpow demoFAQ
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.
How these tools were scored
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Task-level state counts once, Per-task metrics counts once, Restarts counts once, Auto-restart of failed tasks counts once, Alerting counts once and Multi-cluster and access control counts three times, for a total out of 80. Multi-cluster and access control counts three times here, because Connect is where a restart or a credential change reaches production data, and the question of who may press it does not go away while the connector is healthy. Task-level state, per-task metrics, restarts, auto-restart of failed tasks and alerting count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 66 out of 80. The other options follow by total.