Count of enabled workflows that have not enrolled anyone in over a day, a sign trigger criteria broke or a contact property was renamed. Investigate before the next campaign goes out.
At a glance
Workflows Blocked / Stale is the standing KPI count of automation that has quietly stopped working. It counts enabled workflows whose last enrolment was more than 24 hours ago, which almost always means the trigger criteria broke or a referenced contact property was renamed or archived. Unlike the real-time alert version, this card lives on the dashboard as a number to watch: zero is healthy, anything above zero is a list of workflows that look on but are doing nothing. It is the pre-flight check before a campaign launches, because launching new sends on top of a stalled automation layer compounds the silence.
Calculation
Calculated automatically from your HubSpot data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A multi-brand apparel retailer on Marketing Hub Enterprise runs 38 enabled workflows across two brands. Reading on 2 Jun 26, the morning before a large summer-sale send. The card reads 4 blocked/stale workflows. The drill-down:
What the team does with this before launching the sale:
- Three of the four are real breaks, one is benign. The loyalty, back-in-stock, and birthday workflows have broken dependencies. The post-purchase review is just quiet because order volume dipped over a slow couple of days; it will self-clear when orders resume.
- Launching the sale on top of these breaks would compound the loss. The summer-sale send will drive a surge of new orders. With the post-purchase review workflow set to re-trigger normally that is fine, but the back-in-stock and loyalty workflows being dead means a chunk of the sale’s downstream nurture will not fire.
- The fix order is by funnel value. Loyalty-tier upgrade touches the highest-value repeat customers, so it gets fixed first. Birthday club is second because it is a simple property re-point. Back-in-stock needs the deleted list rebuilt, which is the slowest fix.
- The benign one teaches threshold tuning. Because the post-purchase review workflow flags whenever orders are quiet, the team sets a slightly longer staleness threshold for it so it stops appearing in the count during normal slow days, keeping the number honest.
- Zero is the launch-readiness target. The team’s rule is that this card should read zero (or only contain known-benign quiet workflows) before any major campaign. After the three fixes, the count drops and the sale launches clean.
Sibling cards merchants should reference together
This is the standing health count for automation. Pair it with these to act on it and to see the volume baseline:Reconciling against HubSpot
Where to look in HubSpot: HubSpot does not present a single “stale workflows” count; the operator has to open each workflow to see when it last enrolled. The closest native views:HubSpot → Automation → Workflows for the full list, sortable by some columns but not by last-enrolment staleness. HubSpot → Automation → Workflows → (workflow) → Enrollment history to read the last enrolment per workflow, one at a time. HubSpot → Settings → Properties to check whether a property a trigger depends on was renamed or archived.The merchant traditionally audits this by opening workflows one by one, which is why stale workflows often go unnoticed for days. This card maintains the count continuously. Why the count may differ from a manual audit:
Cross-connector reconciliation:
Known limitations / merchant FAQs
The count is above zero but HubSpot shows no workflow errors. Is the count wrong? No. Stale workflows fail silently. A trigger that references a renamed property or a deleted list matches nobody and raises no error, so HubSpot’s error view stays clean while the workflow does nothing. This count is built precisely to catch the failures the error view cannot see. A workflow we run only occasionally keeps appearing in the count. How do we stop that? Mark it as a low-frequency workflow in the profile and give it a longer staleness threshold. The count is meant for workflows that should enrol continuously; rare-trigger workflows need a tolerance that matches their real cadence. What is the difference between blocked and stale? Blocked means the trigger is structurally broken (deleted list, archived property). Stale means the workflow simply has not matched anyone lately, which may be a break or may be benign. The card groups them because the first action is the same in both cases: open the workflow and inspect the trigger. Should this card be zero before a campaign? That is the recommended discipline. Launching a big send on top of stalled nurture and lifecycle workflows means the surge of new contacts and orders the campaign drives will not be picked up by the automation that should follow them. Clear the count, or confirm the remaining entries are known-benign, before launch. Does this card change any workflow? No. It is read-only. It reports which workflows look stalled; re-pointing a trigger or rebuilding a list is a manual fix in HubSpot. How does this relate to the real-time alert? Same underlying signal, different surface. This card is the persistent count you glance at on the dashboard; the Workflow Stopped Enrolling (>24h) alert pings the team the moment a workflow crosses the threshold. Use the alert to react and this count to monitor. Action playbook to drive the count to zero:- Open the drill-down and sort stalled workflows by funnel value or normal enrolment volume.
- For each, inspect the trigger for a renamed property, archived field, or deleted list.
- Fix the highest-value workflows first; one shared dependency may clear several at once.
- For genuinely low-frequency workflows, set an appropriate staleness threshold instead of fixing them.
- Re-check before any major campaign and treat a non-zero count as a launch blocker.