skip to content

Explain the difference between GET /connectors/{name}/status, /config, and /tasks. What does the status endpoint tell you that /config does not?

level: middleimportance: must knowfreq 70%

answer

  1. config = desired, status = runtime
  2. connector RUNNING but tasks FAILED
  3. status has worker_id + trace
  4. monitor tasks[].state not just connector.state
  5. tasks = derived per-task configs

basics

~20 s

/config returns the desired configuration; /tasks returns the per-task configs; /status returns runtime health: the connector's RUNNING/FAILED/PAUSED state plus each task's state, assigned worker, and any failure trace. Status is live; config is static intent.

solid answer

~40 s

These three GET endpoints expose different planes. **/config** returns the connector's persisted configuration (the desired state you submitted). **/tasks** returns the array of generated per-task configurations the connector produced from that config. **/status** is the runtime view: it reports the connector-level state (RUNNING, PAUSED, FAILED, UNASSIGNED, RESTARTING), the worker_id currently hosting the connector, and an array of tasks each with its own state, worker_id, and — crucially — a trace field containing the stack trace when a task is FAILED. The key insight: a connector can be RUNNING at the connector level while individual tasks are FAILED, and only /status surfaces that. /config and /tasks tell you what should happen; /status tells you what is actually happening and why it broke.

go deeper

for a junior

Know that /status shows whether the connector and tasks are running or failed.

for a middle

Distinguish config (desired) vs status (runtime), and know that connector and task states are independent.

for a senior

Build monitoring around tasks[].state and the trace field; explain why connector-level RUNNING is insufficient.

for a principal

Design cluster-wide health/alerting and self-healing loops (status poll -> targeted restart) and reason about leader-driven task placement.

Kafka Connect separates **desired state** (configuration) from **runtime state** (status), and the REST API mirrors that split. **GET /connectors/{name}/config** returns the flat config map you submitted — the *desired state*. It is purely declarative and says nothing about whether the connector is healthy. **GET /connectors/{name}/tasks** returns an array of task objects, each with an `id` ({connector, task-index}) and the `config` map Connect generated for that task. A connector with `tasks.max=3` may produce up to 3 task configs (fewer if there isn't enough work to parallelize — e.g., a source with only 2 tables). This is still *desired/derived* state. **GET /connectors/{name}/status** is the *runtime* view and returns: ``` { "name": "my-connector", "connector": { "state": "RUNNING", "worker_id": "10.0.0.1:8083" }, "tasks": [ { "id": 0, "state": "RUNNING", "worker_id": "10.0.0.1:8083" }, { "id": 1, "state": "FAILED", "worker_id": "10.0.0.2:8083", "trace": "org.apache.kafka.connect.errors.ConnectException: ..." } ], "type": "source" } ``` The possible **states** are: `RUNNING`, `PAUSED`, `STOPPED`, `FAILED`, `UNASSIGNED` (not yet assigned to a worker), and `RESTARTING`. **The critical operational fact:** the connector-level state and task-level states are independent. A connector reports `RUNNING` as long as its Connector instance is alive, even if every task has thrown and is `FAILED`. Data flow happens in tasks, so **monitoring only the connector state hides outages**. Production health checks must inspect `tasks[].state` (and alert on any `FAILED`), not just `connector.state`. The `trace` field is the first thing to read when diagnosing a failure — it's the captured exception that killed the task. **Why two workers appear:** in distributed mode the Connect leader assigns the Connector instance and its tasks across workers for balance, so `worker_id` can differ between the connector and its tasks, and between tasks. That's why /status, unlike /config, includes `worker_id` — it's placement information. **Practical recovery:** a FAILED task does *not* auto-restart. You must call POST /connectors/{name}/restart (with includeTasks/onlyFailed) or POST /connectors/{name}/tasks/{id}/restart. Reading /status to find which tasks failed, then issuing a targeted restart, is the standard remediation loop.

  • A connector shows state RUNNING but no data is flowing. Where do you look?
    GET /connectors/{name}/status and inspect the tasks array — individual tasks can be FAILED while the connector is RUNNING. Read the trace field on the failed task to find the exception.
  • Why might /status report a different worker_id for the connector than for its tasks?
    In distributed mode the Connect leader balances the Connector instance and each task independently across workers, so they can be assigned to different workers.

saying these in an interview costs you the question

  • Saying a RUNNING connector implies healthy tasks — they are independent; tasks can be FAILED.
  • Confusing /config (desired) with /status (runtime).
  • Claiming failed tasks auto-restart — they don't; you must call a restart endpoint.
  • Thinking /tasks returns task runtime state — it returns derived per-task configs, not health.

context

resolving links…