Skip to main content
Your trigger did not turn off at random. Gumloop pauses a trigger automatically after 3 consecutive failed runs. It is a safeguard: a trigger that keeps firing into the same error burns credits and piles up failed runs, so Gumloop turns it off until the cause is fixed. This applies to every trigger type: scheduled, app, webhook, and AI-created custom triggers.
When a trigger auto-disables, the owner is notified by email, Slack DM, and in app. The notification links straight to the most recent failed run, which is the fastest way to see what went wrong. Dismiss it once you have handled it.

​
Why it turned off

​
Find the cause

The trigger being off is the symptom. The failed runs tell you the cause.
  1. Open the notification and click through to the failed run. Or open the agent and go to its run history.
  2. Read the last few failed runs from just before it turned off. The error on those runs is the real reason.

​
Common causes and fixes

Ordered by how often they come up:

​
Turn it back on

  1. Fix the cause first. Re-enabling without fixing it just disables the trigger again on the next runs.
  2. Open the agent and go to the Triggers tab.
  3. Open the trigger’s menu and choose Activate trigger.
Re-enabling resets the failure count. Only failures after you re-enable count toward the next auto-disable, so earlier failures will not turn it off again on their own. You can activate your own trigger if Create triggers is Allow. Otherwise ask an Owner or Org Admin to activate it. Owners and Org Admins can also activate other people’s triggers. See Who Can Manage Triggers?.
If the trigger turns off again right away, the root cause is still there. The classic example is a credential you refresh but that keeps expiring, such as a Salesforce connected app whose refresh token policy is not set to stay valid until revoked. Fix the source of the repeated failures, not just the trigger.

​
Stop it from happening again

  • Keep credentials healthy. Refresh the connector before its access expires. For a shared automation, use a team connector so one person leaving does not break it.
  • Keep credits above zero on the account that owns recurring triggers.
  • Fire only on new data. If a trigger fires on every poll instead of only on new data, it wastes credits and its runs start getting skipped. Tighten the condition.

​
FAQ

Not from the app. Fix the error that keeps failing, or handle it in the agent so the run finishes successfully.
No. The schedule, prompt, and settings stay intact. Re-enabling picks up exactly where it left off.
Check whether it was a one-time scheduled trigger. Those delete themselves after they run, success or fail, so a missing one-time trigger ran, it did not fail. Otherwise, someone with access deleted it, or the creator lost all access to the agent, which removes their triggers. Removing one share does not remove them if another grant still provides access.
If the connector the trigger was built on was revoked or deleted, re-enabling will not fix it. The trigger still points at a credential that no longer exists, and connecting the app again creates a new one rather than restoring the old one. Delete the trigger and create it again on the reconnected account. This is the most common reason a trigger keeps failing after what looks like a clean fix.

Stop a scheduled trigger

Deactivate or delete a trigger yourself.

Who can manage triggers?

Owner and User permissions.

Revoke and reconnect a connector

Fix an expired or disconnected credential.

Agent triggers

How scheduled, app, and webhook triggers work.