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. If it tripped because the account spend cap was reached, there is no Resume button: dispatch resumes automatically once the cap is raised or the billing period rolls over, and the banner offers Adjust cap instead. 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.
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 "Run a test to see output data here."
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 Logs at /{workspaceSlug}/monitoring/logs. Filter the Level to Error and check the Event Type column for workflow.started entries around the time you expected events. If you see no workflow.started events at all in a window where the external system was sending, the events are not reaching a run; if you see workflow.failed, the events arrived but the run failed, which points you back to Read a failed run.
TaskJuice does not keep a standalone list of rejected inbound events. The Workflow Runs list shows only events that produced a run. To trace a silent trigger, use the reauthorization banner and the monitoring Logs above, not a rejected-events screen.
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.
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.