Why a run paused and how it resumes

A run that stops before it finishes is not always broken. TaskJuice deliberately holds work in several situations: a credential expired, a step needs a human decision, the workflow tripped a safety limit, or your spend cap was reached. Each of these looks slightly different in the run list, and each resumes through a different action. Picking the wrong recovery step is the most common reason a held run sits longer than it needs to.

This page builds the mental model: which signal you are looking at, why the run stopped, and the one thing that gets it moving again.

Paused is not the same as waiting

Before the reasons, separate two words that are easy to conflate, because they resume differently.

A run with status paused (yellow badge, pause icon) was stopped by a person or by a safety decision. It will not move on its own. You resume it.

A run with status waiting (blue badge, clock icon) is parked on something it expects to receive: a delay timer, a form submission, an approval decision, a sub-workflow, or an agent callback. It resumes when that thing arrives or the timer fires. You usually do not press a button.

There is also a third, separate idea. A whole workflow can carry the status paused-safety, labeled Paused (safety) with a yellow warning triangle. That is the workflow itself being held by a safety breaker, not a single run being paused. It stops every new run from dispatching until you clear it. The throughput and spend-cap reasons below are workflow-level safety pauses; reauthorization and approval are run-level holds.

Reason 1: a connection needs reauthorization

When a step uses a connection whose access token can no longer be refreshed, TaskJuice stops the run rather than firing a call it knows will be rejected. A single expired token blip does not trigger this. TaskJuice retries transient refresh failures with backoff on its own. Only a permanent refresh failure puts the connection into its error state and holds the run.

You learn about it two ways. A red reauthorization banner appears in the app, and the runs list gets a Paused for reauth filter chip so you can find every run blocked on the same cause. With one affected connection the banner reads "A connection needs to be reauthorized"; with several it reads "3 connections need to be reauthorized" plus an overflow line pointing you to the notification bell for the full list. The banner row links straight to the connection that needs attention, titled with the app name, for example "Slack reauth required".

The fix is to reconnect the integration. Reconnecting re-runs the authorization for that connection, mints fresh tokens, and flips the connection's status back to active. Ordinary runs that were paused for reauth resume when you press Resume on the run detail page after reconnecting. Agent-mode runs (the ones that show an Awaiting reauth pill) return to running on their own once the reconnection completes; no manual resume needed.

If you try to refresh a connection manually and it has permanently failed, you will see this exact response:

Connection cannot be refreshed. Please reconnect your connection.

That message means the retry path is exhausted. Reconnect from scratch rather than refreshing again.

Reason 2: a step is awaiting approval

Some actions are gated behind a human decision. When a run reaches a gated action, it routes the decision to an approval task and parks the run until someone responds. The run sits in a wait state; agent-mode runs display an Awaiting approval pill that links to the Approvals inbox.

An approval task carries a status of pending, approved, denied, or expired, and starts at pending. Each task has an expiry time and a timeout policy that decides what happens if nobody responds in time. The policy is one of deny, proceed, or escalate, and the default is deny, meaning an ignored approval blocks the action rather than letting it through.

To resume, an approver decides in the Approvals inbox at /{workspaceSlug}/monitoring/approvals. Approvers can also respond from Slack, a magic link, or email, depending on how the approval was sent. Approve and the run continues from where it parked. Deny and the gated action does not run. If the task expires first, the timeout policy applies.

Each approval also records how reversible the gated action is, classified as safe, recoverable, or irreversible. Treat an irreversible approval, for example a payment or a permanent delete, as the one to read carefully before you approve, because there is no clean undo afterward.

Reason 3: throughput tripped a safety breaker

TaskJuice watches how fast a single workflow is firing. A workflow that runs away, usually a loop or a polling trigger that was misconfigured, can generate work far faster than intended. When that happens the safety breaker trips the whole workflow to paused-safety with the trip reason that it exceeded the throughput cap. The safety banner explains the cause: the workflow "tripped the throughput cap (likely a loop or polling misconfig)".

This is a workflow-level pause, so it stops new dispatch for that workflow, not just one run. The cause is almost always in the workflow design: a loop with no bound, a Switch that feeds back on itself, or a polling interval set far too low.

To resume, fix the misconfiguration first, then click Resume workflow on the safety banner. Resuming before you fix the loop will trip the breaker again on the next surge.

Reason 4: the spend cap was reached

Your workspace has a monthly spend cap, and TaskJuice reacts to it in two stages.

The soft stage is a warning only. As spend approaches the cap, TaskJuice sends an email, a Slack message, and an in-app notification, and the run viewer shows a yellow near-cap indicator. Nothing stops. Runs keep executing through the soft warning so a busy month does not silently halt your automations.

The hard stage blocks. When spend reaches the cap, the safety breaker can pause the workflow to paused-safety with the spend-cap trip reason. The banner reads: "This workflow paused because the account spend cap was reached. Dispatch resumes after the cap is raised or the billing period rolls over."

This is the one pause that has no manual resume button, and it surprises people who expect every pause to work the same way. There is no Resume workflow for a spend-cap pause. The safety banner instead shows an Adjust cap button that links to billing at /{workspaceSlug}/billing. Dispatch resumes on its own once you raise the cap or the billing period rolls over to a new month. You do not press resume; you change the limit or wait for the reset.

Reason 5: someone paused it on purpose

The simplest case. A teammate pressed Pause on a running or pending run, perhaps to inspect it or to stop a call before it landed. There is no error and no breaker involved. The run sits at paused until someone presses Resume on the run detail page, or cancels it. This is also why you should check who paused a run before assuming something failed; a manual pause looks identical to a safety pause in the badge color, but it carries no banner.

What you cannot resume yourself

A few stops are platform guardrails, not holds you can clear. If a step is rejected because the platform rejected the call outright (rather than pausing the workflow), the run fails rather than parking. These guardrails protect the platform from abuse and exist below anything you configure. When you hit one, the run shows as failed with an error on the rejected step rather than as paused, so read the failed step's error to tell the two apart. A paused or safety-paused run is recoverable through the actions above; a failed run is not resumed, it is replayed after you fix the cause.

How to tell which reason you are looking at

Work from the signal in front of you:

1. Read the badge first

   A paused run badge means a person or a run-level hold stopped it; look for a banner. A waiting badge means it is parked on an external event like an approval or a delay. A workflow showing Paused (safety) means a breaker tripped.

2. Look for a banner

   A red reauthorization banner points to reason 1. A yellow safety banner names its own trip reason: throughput points to reason 3, spend cap points to reason 4. No banner on a paused run usually means a teammate paused it manually (reason 5).

3. Match the resume action to the reason

   Reauth and operator pauses resume with Resume on the run. Approvals resume from the Approvals inbox. The throughput safety pause resumes with Resume workflow after a fix. The spend-cap pause has no Resume button; use Adjust cap or wait for the period to roll over.

Related

• Reconnect an integration walks the full reauthorization fix and resume.
• Run and step statuses defines every status and its next action.
• Usage and overage explains the monthly spend cap and how to adjust it.