Fix a trigger that is not firing
No runs are showing up? Confirm your workflow is published and active, send a test payload, and find out where events get dropped.
You built a workflow, connected the trigger, and nothing happens. No runs appear on the Workflow Runs list, the external app keeps sending data, and the workflow looks fine in the editor. This page walks the three checks that resolve almost every "no data coming in" report: confirm the workflow is published and the version is active, test the trigger directly, and find out where events are being rejected before they ever become a run.
When to use this
Work through these steps when the external system is sending events but no runs show up at /{workspaceSlug}/monitoring/workflow-runs. If runs are appearing but failing, go to Read a failed run instead. If a run started and then stopped partway, see Why a run paused.
The Workflow Runs list only shows events that produced a run. An event that never started a run will not appear there at all, which is why a silent trigger looks like nothing is happening.
Confirm the workflow is published and active
A workflow only receives live events when two things are both true: the workflow status is Published, and the version you edited is the active version. A draft or inactive version receives no live events even though you can still open and edit it.
Check the workflow status badge
Open the workflow. The status badge near the workflow name must read Published. Hover it and the tooltip should say "Active and dispatching."
If it shows anything else, that is your answer:
Badge Tooltip What it means Draft "Draft, not yet published." The workflow has never gone live. Publish it. Disabled "Disabled by operator. Re-enable to resume dispatch." Someone turned it off. Re-enable it. Archived "Archived, no longer dispatching." The workflow was retired and will not run. Paused (safety) "Paused by safety breaker. Resume from the workflow page after fixing the misconfiguration." A safety limit tripped. See the step below. Confirm the version is active
In the editor header, the activation toggle shows Active when the version you are looking at is the one receiving events. If it shows Inactive, the version is activatable but not live. Turn it on.
If the toggle is disabled, hover it for the reason. "Workflow must be in draft or failed status to activate (current: ...)" means a different version is already active, and "Deprecated workflows cannot be activated" means this version was retired. Publishing recompiles the version; you will see "Compiling workflow..." then either "Workflow compiled and activated successfully" or "Workflow compilation failed". A failed compile leaves the version in the Failed state and nothing goes live. See Fix publish errors to resolve the compilation message.
A workflow in Paused (safety) still looks live at a glance, but it has stopped receiving events. A safety banner on the workflow page names the reason. If it tripped on throughput (often a loop or polling misconfiguration), fix the workflow and click Resume workflow. A reached account spend cap looks similar from the outside, since events stop producing runs, but it does not set Paused (safety): the workflow keeps its status, its trigger activity rows read Spend cap reached, and runs start again once the cap is raised or removed, or the billing period rolls over. See Why a run paused for both paths.
Confirm the trigger is wired to the external system
For a webhook trigger, the trigger node panel shows a generated Webhook URL in its setup section. The external system has to POST to that exact URL. A common cause of silence is a stale or wrong URL pasted into the other app: a typo, a trailing slash, the test URL instead of the live one, or a URL copied from a different workflow.
Open the trigger node, copy the Webhook URL from the panel, and compare it character for character against what the sending system is configured to call.
App Webhook triggers for apps TaskJuice registers automatically (such as ActiveCampaign, Calendly, and Close) have no URL to copy — the panel never shows one, because the registration is not yours to wire. Open the trigger node and read the setup status instead: it says when registration is still underway, confirms when the app is set up and sending events here, and names what to fix when registration could not finish. If the status names an action — reconnecting the app, removing unused webhooks — do that, then republish.
Test the trigger directly
The trigger node panel has two test affordances. Use them to prove the workflow can produce a run on its own, independent of whatever the external system is doing.
For a webhook trigger, the panel shows a Test node button: "Send a test payload through the webhook trigger to validate configuration and mapping." Use this to check that the trigger accepts a payload and that your field mapping reads it correctly. Output appears in the panel; until you run a test it reads "No output yet" and "Test this step to see its output."
If a test produces output and a run, the workflow itself is sound and the problem is upstream: the external system is not reaching your Webhook URL, or it is reaching it but the event is being rejected (next section). If a test produces nothing, the trigger configuration or mapping is the problem, and the panel output is where to look.
Find out where events are being dropped
When the workflow is published and active and a test works but live events still produce no runs, the events are being rejected before they become a run. Two causes account for most of this, and both surface as a symptom you can see rather than a dropped-events list.
The most common cause is a connection that needs reauthorizing. When a trigger's connection can no longer refresh its token, the trigger stops firing and you get a red reauthorization banner reading "A connection needs to be reauthorized" (or "N connections need to be reauthorized" when more than one is affected), plus an unread item in the notification bell. The banner links to your connections, where you re-run the connect flow to mint fresh tokens. See Reconnect an integration for the full flow.
The other place to look is the monitoring Activity feed, which records what happened before a run existed: trigger checks, rejected inbound requests, and dispatches. If Activity shows no dispatch at all in a window where the external system was sending, the events are not reaching a run; if it shows a dispatch whose run then failed, the events arrived and the run is where the problem is, which points you back to Read a failed run.
The Workflow Runs list shows only events that produced a run, so a rejected event never appears there. Rejections are grouped in the Activity feed by reason rather than kept one-per-request, and they are held for a short window — long enough to tell you a sender is being turned away, not long enough to be a history.
A feed or polling trigger keeps failing
An RSS or polling trigger checks its source on a schedule. When those checks fail, the trigger keeps checking, but nothing new comes in. Open Monitoring → Activity and select the trigger:
- Failing status. The header's status reads Failing, with one sentence underneath saying why and how many times in a row it has failed. Failing is not stopped: the trigger is still on, and the next good check clears it. Last check shows the time of the latest attempt, with Failed beside it when that attempt failed, and Next check shows when the next real check runs (Off when the workflow is off). Not scheduled means no check is queued right now; the next one is scheduled by itself, so there is nothing to fix.
- The details panel. Each failed check in the timeline shows a short label, such as Refused · 403. Click it to open the details: the plain sentence, a hint, the status, the site's host name, when it was checked, and the technical message. Copy copies all of it for a support request, and Trigger settings opens the trigger node.
- Check now. The Check now button runs a real check straight away rather than waiting for the next one. It works once a minute and never more often than your plan's check interval. If the site asked for a pause, or the trigger was checked moments ago, the message says how long to wait.
What the common messages mean:
| Message | What it means | What to do |
|---|---|---|
| refused the request (401 Unauthorized / 403 Forbidden) | The site turned the request away. Many sites block automated requests from servers, or need you to sign in. | Open the address in a browser. If the site has an app in the catalog, use it instead of a public feed. |
| says the address doesn't exist (404 Not Found) | The feed or request address is wrong, or the site removed it. | Fix the address in the trigger's settings. |
| took too long to answer | The site did not answer in time. | Usually temporary. Checks continue on schedule. |
| answered, but not with an RSS or Atom feed | The address returned a web page, often a sign-in or "blocked" page, instead of a feed. | Check the feed address. |
Verify it worked
Send a real event from the external system, or use Test trigger in the editor. Then open /{workspaceSlug}/monitoring/workflow-runs and confirm a new row appears with a recent Started time. The list does not auto-refresh on its own; click Refresh if the new run has not shown up yet. A run row with any status, even Failed, means the trigger is firing again and you have moved from "no data coming in" to debugging an individual run.
Troubleshooting
A test works but live events never arrive. The workflow is fine; the external system is not POSTing to your Webhook URL. Re-copy the URL from the trigger panel and reconfigure the sending app. Confirm the sending app is not paused or pointed at a different environment on its side. For an automatically registered App Webhook trigger there is no URL to re-copy — the trigger panel's setup status is what tells you whether the app is still registered, and what to do if it is not.
The reauthorization banner keeps coming back. A connection whose token cannot be refreshed will keep raising the banner until you reconnect it. A single transient network blip does not trigger this; the banner appears only after a refresh permanently fails, so treat it as a real reconnect, not a temporary glitch. See Reconnect an integration.
The workflow shows Published but still no runs. Check whether it is actually Paused (safety), which can be mistaken for Published at a glance. The safety banner on the workflow page names the trip reason and tells you how to resume.