skip to content

Walk through pausing, stopping, and resuming a connector via the REST API. How do PUT /pause, PUT /stop, and PUT /resume differ?

level: middleimportance: should knowfreq 50%

answer

  1. pause = PAUSED, tasks stay warm
  2. stop = STOPPED, tasks de-allocated (KIP-875, 3.5)
  3. resume from either -> RUNNING
  4. STOPPED required for /offsets
  5. all PUT, empty body, 202 async

basics

~10 s

PUT /connectors/{name}/pause halts processing but keeps tasks assigned (state PAUSED). PUT /connectors/{name}/stop also halts but de-allocates the tasks (state STOPPED), freeing cluster resources. PUT /connectors/{name}/resume restarts a paused or stopped connector back to RUNNING.

solid answer

~40 s

All three are PUT requests with empty bodies. **PUT /pause** transitions the connector and its tasks to PAUSED: tasks stop processing but their assignments and Task objects are retained, so resuming is fast. **PUT /stop** (added in Kafka 3.5 / KIP-875) transitions to STOPPED: tasks are shut down and de-allocated entirely, releasing worker threads and rebalancing slots — a lighter-weight idle state, and the recommended way to hold a connector for a long time or before deleting cleanly. **PUT /resume** brings either a PAUSED or STOPPED connector back to RUNNING, re-creating tasks if they were stopped. A key practical difference: STOPPED still keeps the connector's config and committed offsets, and it's the prerequisite state for the offset-management endpoints (GET/PATCH/DELETE /offsets), whereas PAUSED keeps tasks warm but consuming resources.

go deeper

for a junior

Know pause halts and resume restarts a connector via PUT.

for a middle

Distinguish pause (warm) vs stop (de-allocated), and that resume works from both.

for a senior

Tie STOPPED to the offset-management workflow and to freeing cluster capacity; account for async 202 behavior.

for a principal

Reason about capacity management across a multi-connector cluster and design safe offset-reset runbooks using stop/resume.

Kafka Connect offers three lifecycle hold/resume operations, all issued as **PUT** with an empty request body and returning **202 Accepted** (the transition is asynchronous — the cluster rebalances to apply it). **PUT /connectors/{name}/pause** — moves the connector to **PAUSED**. The Connector and Task objects remain instantiated and assigned to their workers; they simply stop calling poll()/put(). Because the tasks stay warm, resuming is near-instant. Downside: paused tasks still hold their worker thread/slot and Kafka client connections — they consume resources even while idle. **PUT /connectors/{name}/stop** — moves the connector to **STOPPED** (introduced by **KIP-875** in Kafka 3.5). Unlike pause, this shuts the tasks down completely and de-allocates them, triggering a rebalance that frees those slots for other connectors. The connector's configuration and committed source/sink offsets are preserved. STOPPED is the intended state for: (a) holding a connector idle for a long time without wasting capacity, (b) the precondition for the **offset management** endpoints — `GET/PATCH/DELETE /connectors/{name}/offsets` require the connector to be STOPPED so offsets can be read or rewritten safely, and (c) a clean shutdown before delete. **PUT /connectors/{name}/resume** — moves a PAUSED or STOPPED connector back to **RUNNING**. From PAUSED the warm tasks simply resume; from STOPPED the tasks are re-created and re-assigned. **Mental model:** PAUSE = parked with the engine running (fast restart, fuel burning); STOP = engine off, key in pocket (slower restart, no fuel burn, and only now can you safely service the offsets). **Edge cases:** - These transitions are cluster-wide and survive worker restarts because the desired target state is persisted to the Connect config topic. - Because they're asynchronous (202), immediately polling /status may still show the prior state until the rebalance completes. - Pausing/stopping does not delete the connector or its config; only DELETE /connectors/{name} removes it. - Sink connectors that are paused stop committing offsets; on resume they continue from the last committed position (at-least-once semantics still apply).

  • You need to rewrite a connector's committed offsets. What lifecycle state must it be in and which endpoints do you use?
    It must be STOPPED (PUT /stop). Then use GET /offsets to read, PATCH /offsets to alter, or DELETE /offsets to reset, then PUT /resume.
  • Why prefer stop over pause for a connector idle for days?
    Stop de-allocates tasks and frees worker slots/threads/clients, so cluster capacity isn't wasted; pause keeps tasks warm and consuming resources.

saying these in an interview costs you the question

  • Saying pause and stop are the same — stop de-allocates tasks; pause keeps them assigned.
  • Claiming pause deletes config or offsets — it doesn't; only DELETE removes the connector.
  • Thinking offsets can be edited while RUNNING or PAUSED — the connector must be STOPPED.
  • Expecting the transition to be synchronous — these return 202 and apply via rebalance.

context

resolving links…