Start with recovery, not connector count
The fastest way to evaluate a tool is to ask one question: what is the smallest safe point to resume from? For some integrations, that is a single record. For others, it is a batch. For multi-step flows, it may be a handoff between systems. The right tool makes that boundary obvious and keeps it durable.
The non-negotiables
- Durable state: checkpoints must survive worker restarts, deploys, and crashes.
- Clear resume points: operators should be able to see the last good step or batch quickly.
- Replay-safe writes: rerunning should not create duplicate downstream actions.
Compare tools by recovery behavior
A feature list can be misleading. What matters is how the tool behaves after a partial failure.
| Decision point | What strong tooling shows | Why it matters |
|---|---|---|
| Checkpoint storage | State lives in a durable store outside worker memory | Progress survives process loss |
| Resume boundary | Restart by step, record group, or batch | Safe work is not repeated |
| Attempt history | Attempt number, timestamp, and failure stage | Incident review is faster |
| Replay protection | Dedupe keys or idempotent actions | Duplicate side effects are less likely |
| Operator controls | Pause, resume, rerun subset, or quarantine a bad record | Support can handle narrow failures without restarting everything |
Connector breadth is useful, but it does not solve recovery. A large library of app connections still leaves the team stuck if the workflow cannot resume cleanly after a partial failure.
Match the tooling to the job shape
Record-level jobs
Use record-level control for enrichment, cleanup, validation, and other jobs where one bad row should not block the rest. This setup needs a way to isolate failures, quarantine problem records, and keep the batch moving.
The trade-off is more exception handling. Record-level restartability is powerful, but only if the error queue stays organized and someone owns triage.
Batch-level jobs
Batch checkpoints fit nightly syncs, imports, exports, and file-based workflows. They work well when data moves in clean groups and when rerunning a small set of records is easier than replaying the entire job.
The trade-off is coarser recovery. If one record poisons the batch and the tool cannot separate it from the rest, the rerun may still be broader than you want.
Workflow-level jobs
Use workflow-level controls for billing, fulfillment, partner handoffs, and other jobs that cross multiple systems. These flows need audit trails, step visibility, and sometimes compensation steps when a downstream system rejects part of the work.
This is the hardest category to manage. More moving parts mean better control over failures, but they also increase the need for ownership, monitoring, and clear operational rules.
When simpler tooling is the better choice
Not every integration needs heavyweight restart logic. If a job finishes quickly, has no external side effects, and is cheap to run again, a simple rerun path is often enough. Scripts with clean reruns, queue-based processing, or basic rate limiting can be the better choice for short atomic jobs and one-off backfills.
The line is easy to see: if a failure creates cleanup work in another system, restartable tooling starts to matter more. If a rerun is cheap and safe, extra recovery features can add more upkeep than value.
Common mistakes that make restartability fail
- Treating retries as restartability. A retry reruns the failed step; restartability resumes from a clean boundary.
- Storing checkpoints where the worker keeps them only in memory. If the process dies, the resume point dies too.
- Relying on logs alone. Logs explain the failure, but they do not restore progress.
- Ignoring duplicate side effects. If reruns can write the same output twice, recovery is still broken.
- Choosing the biggest connector set first. Recovery behavior matters more than breadth.
What good tooling should make easy
Good restartable tooling should make the recovery path feel procedural, not interpretive. An operator should be able to answer these questions quickly:
- Where did the job stop?
- What has already completed?
- What is safe to replay?
- What needs a manual decision?
If those answers are hard to find, the tool pushes failure handling back onto the team.
Verdict
Look for durable checkpoints, explicit resume boundaries, visible attempt history, and replay-safe writes. Choose stronger restartable tooling when jobs touch external systems, partial failures are common, or cleanup is expensive. Choose simpler tooling when reruns are cheap, isolated, and easy to repeat.
The best tool is the one that turns failure recovery into a clear next step instead of a fresh investigation.
Frequently asked questions
What is the difference between retryable and restartable?
Retryable jobs repeat failed work. Restartable jobs continue from the last known good point. If a failure after most of the job is complete still forces a full replay, the tool is behaving like retry logic, not restartable tooling.
Where should checkpoint state live?
Checkpoint state should live outside worker memory and outside the write path that receives the output. That keeps the resume marker safe when the worker restarts or the target system has trouble.
Do restartable jobs need exactly-once delivery?
No. In most integration workflows, idempotent actions and dedupe controls are more practical than trying to force exactly-once behavior everywhere.
When should a team avoid restartable tooling?
Avoid it when the job is short, atomic, and cheap to repeat. If a rerun is quick and does not create cleanup work elsewhere, a lighter setup is easier to operate.