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 step needs a human decision, a teammate paused the run, or the workflow tripped a safety limit. Each of these looks slightly different in the run list, and each resumes through a different action. Two cases are related but different: a connection that needs reauthorization fails the step that uses it rather than holding the run (Reason 1), and a reached spend cap stops new runs from starting and never holds a run that is already in progress (Reason 4). 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 is parked on an approval decision. A run paused by a person will not move on its own; you resume it. A run parked on an approval shows Waiting for approval in the runs list and on its run page, and resumes when an approver decides (Reason 2).

A step with status waiting (blue badge, clock icon) is parked on something it expects to receive: a delay timer, a form submission, a sub-workflow, or an agent callback. The run around it keeps the status running. 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 reason below is a workflow-level safety pause; an approval is a run-level hold. The spend cap is different again: it refuses new runs at the account level without changing any workflow's status.

Reason 1: a connection needs reauthorization

When a step uses a connection whose access token can no longer be refreshed, TaskJuice fails the step rather than firing a call it knows will be rejected, so the run ends as failed. It does not hold the run. 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.

You learn about it from a red reauthorization banner in the app. 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. Reconnecting does not restart a run that already failed. Once the connection is active, retry the failed run, or let the next trigger event run the workflow. See re-run the failed work.

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

A step waits for a human decision when its node is set to Pause for approval, and nothing else pauses a step for approval. When a run reaches such a step, it routes the decision to an approval task and parks the run until someone responds. The run reads paused. A run parked on a gated action step shows Waiting for approval in the runs list and on its run page, and that Status option lists only runs waiting for an approval. The workspace sidebar's Runs item counts every approval waiting. A run whose AI agent is waiting on a gated tool call stays running, but the runs list still shows it under Waiting for approval, and so does its run page's status badge, and its page shows an Awaiting approval pill that links to the agent's step.

An approval task carries a status of pending, approved, denied, or expired, and starts at pending. Each task has an expiry time. If nobody decides before it expires, the task is rejected, so an ignored approval blocks the action rather than letting it through.

Approver groups, the named sets of people a paused step can ask, are managed per workspace in Settings → Approvers. Each step set to pause for approval names who it asks: a person, a group, or the client.

To resume, an approver opens the run and decides on the waiting step, which the approval link expands. For an AI agent's tool call, that is the agent's step, where each waiting call has its own Approve and Reject buttons. An approval that no step can show is listed under Waiting for approval in this run, above the steps. The approval email and Slack message each carry one link. After you sign in, it opens the run on your workspace's own address with the gated step in view; a client lands on the same run in their portal. The in-app notification opens the run page directly. Approve and the run continues from where it parked. Reject and the gated action does not run. If the task expires first, it is rejected. There is no Resume button on such a run. An approver can also decide it from a connected AI assistant, as themselves, through a sign-in connection with the Admin permission (see Decide approvals).

A step set to pause for the client is decided by the workspace's clients in their portal. The run's page there shows them a Waiting for your approval card with the step's details, and they can approve, edit the step's values, or reject it. You can still decide it from the agency run page. See What your clients see in the portal.

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

The monthly spend cap is optional, and it applies to overage only: usage beyond your plan's included amounts, at overage rates. Your plan's base price never counts toward it, and an account with no cap never pauses for spend. See Usage and overage to set, change, or remove it.

The warning stage never stops anything. With a cap set, TaskJuice emails the account's owners and admins when your projected overage for the period is on pace to reach 60% or 80% of the cap, and from 80% the billing overview shows an amber Approaching spend cap banner. Runs keep executing through these warnings so a busy month does not silently halt your automations.

The pause stage starts only when your actual overage for the period reaches the cap. From then on, TaskJuice refuses to start new runs: the trigger activity row shows Spend cap reached, the billing overview shows a red Spend cap reached banner, and the owners and admins get an email saying new runs are paused. Runs already in progress finish. Each workflow keeps its status, so nothing is set to paused-safety and there is no workflow to resume. A manual run you start from the editor with custom JSON input is not checked against the cap.

New runs are accepted again as soon as you raise the cap above your overage so far or remove it, from Adjust cap on Settings → Spend at /settings/spend, or when the billing period rolls over. You do not press resume; you change the limit or wait for the reset.

The cap stops new runs; it is not a kill switch. Your overage can end up slightly above the cap by the cost of runs already in progress when it is reached, plus a few seconds of usage still being recorded. At a steady spend rate, that is roughly your spend per second multiplied by the time it takes to record usage (normally a few seconds) plus the running time of your longest workflow.

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 retried 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 stopped it. A run waiting on an approval reads Waiting for approval, in the runs list and on the run's own page. A workflow showing Paused (safety) means a breaker tripped.

2. Look for a banner

   A red reauthorization banner next to a failed run points to reason 1. A red safety banner names its own trip reason; throughput points to reason 3. A Spend cap reached trigger activity row, with a red spend-cap banner on the billing overview, 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

   Operator pauses resume with Resume on the run. A run that failed on a broken connection is not restarted; start a new run after you reconnect. Approvals resume when an approver opens the run and decides on the waiting step. The throughput safety pause resumes with Resume workflow after a fix. The spend cap has no Resume button; raise or remove the cap, or wait for the period to roll over.

Related

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