> ## Documentation Index
> Fetch the complete documentation index at: https://learn.workflow.dog/llms.txt
> Use this file to discover all available pages before exploring further.

# Enable and pause workflows

> Control whether new trigger events are allowed to execute a workflow.

A workflow is either **Live** or **Paused**.

* **Live** workflows accept trigger events and queue runs when project usage
  requirements are satisfied.
* **Paused** workflows reject newly created runs before execution.

New workflows start Paused so you can configure the trigger and graph before
allowing events to execute actions.

## Enable a workflow

<Steps>
  <Step title="Finish the trigger configuration">
    Open the trigger drawer, select any required account, and complete the
    trigger-specific settings.
  </Step>

  <Step title="Wait for the graph to save">
    Confirm the editor shows **Saved**. Enabling does not force a pending graph
    save to finish first.
  </Step>

  <Step title="Check integrations and billing">
    Confirm selected accounts are healthy. For billable triggers, confirm the
    project has run credits or active usage billing.
  </Step>

  <Step title="Set the workflow Live">
    Open the status menu at the top of the editor and choose **Enable Workflow**.
    The status changes to **Live**.
  </Step>

  <Step title="Send a new test event">
    Trigger the workflow and inspect its new run in **Run History**.
  </Step>
</Steps>

## Pause a workflow

Open the **Live** status menu and choose **Pause Workflow**. The status changes
to **Paused**.

Pausing is immediate for runs created after the status update, but it is not a
subscription teardown or queue purge.

<Warning>
  Pausing does not cancel runs that are already Scheduled. Those delayed runs
  remain queued and can execute at their scheduled time. Cancel each Scheduled
  run from run history when it must not execute.
</Warning>

## What happens to events while paused

External trigger subscriptions remain configured while the workflow is
paused. When a trigger event tries to start the workflow:

1. WorkflowDog creates a run record from the event.
2. The eligibility check sees that the workflow is paused.
3. The run is marked **Failed** with **The workflow is paused**.
4. The event is not queued for later execution.

Enabling the workflow later does not replay these paused-event failures.

The same rule applies to manually choosing **Re-run** while the workflow is
paused: the new run fails the paused eligibility check.

<Note>
  Keeping the external subscription configured makes pause and resume fast and
  avoids repeatedly creating provider webhooks or watches. It also means run
  history can show failed paused events.
</Note>

## Pausing and scheduled work

A Schedule Workflow action reserves and queues its delayed run when the parent
workflow executes. The destination workflow's Live or Paused state is checked
at that queueing moment.

If the destination is Live when the run is scheduled and becomes Paused later,
the existing Scheduled run is not checked again before execution. Cancel it
explicitly if the pause should include already scheduled work.

## Pausing and integrations

Pausing does not:

* Disconnect integration accounts.
* Revoke provider permissions.
* Remove Gmail watches, Microsoft subscriptions, or other external event
  sources.
* Clear trigger configuration.

Use [Integrations](/essentials/integrations) to replace or disconnect an
account. See [External triggers](/essentials/external-triggers) for the
subscription lifecycle.

## Billing can still stop a Live workflow

**Live** means the workflow is allowed to run; it does not bypass project usage
checks. A Live workflow can create a Failed run when:

* The project has no run credits and no usage subscription.
* The subscription exists but its payment state does not allow new usage.

Resolve the project issue under
[Usage and billing](/essentials/usage-and-billing), then send a new event or
manually re-run the saved payload.

## When to pause

Pause a workflow when:

* Editing actions that send messages or change external data.
* Rotating an integration account.
* Investigating repeated bad inputs.
* Preventing new work while you cancel already Scheduled runs.

For a planned account migration, pause first, swap action usages, reconfigure
the trigger, confirm the new account is healthy, and then enable the workflow.

## Troubleshooting

<AccordionGroup>
  <Accordion title="A run executed after I paused the workflow">
    Check whether it was already in Scheduled status before the pause. Pausing
    blocks newly queued work but does not cancel delayed runs that were already
    accepted.
  </Accordion>

  <Accordion title="Run history fills with The workflow is paused">
    The trigger subscription is still receiving events. This is expected while
    paused. Enable the workflow when ready, or reconfigure/disconnect the trigger
    source when you need events to stop at the provider.
  </Accordion>

  <Accordion title="The workflow is Live but new runs fail immediately">
    Open the failure tooltip. Out-of-credit and invalid-payment failures are
    project billing problems, while a worker failure is an execution-system
    problem.
  </Accordion>

  <Accordion title="Re-run fails without executing any nodes">
    Confirm the workflow is Live and the project can accept billable runs. A
    manual re-run goes through the same pause and billing checks as a trigger
    event.
  </Accordion>
</AccordionGroup>