> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workflows Blocked / Stale, HubSpot > Workflows Blocked / Stale: 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. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Email Marketing](/nerve-centre/connectors#connectors-by-type) > 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. | | | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | The count of enabled workflows whose most-recent enrolment is older than 24 hours. The drill-down lists each stalled workflow with its name, last-enrolment time, trigger type, and silent-duration. | | **Blocked vs stale** | "Blocked" workflows have a structurally broken trigger (deleted list, archived property, impossible criterion). "Stale" workflows simply have not matched anyone recently. The card groups both because the operator action (investigate the trigger) is the same. | | **Enabled-only** | Paused and draft workflows are excluded; a turned-off workflow not enrolling is expected, not stale. | | **Cadence tolerance** | Workflows that legitimately enrol infrequently can carry a longer staleness threshold in the profile so they do not inflate the count during normal quiet periods. | | **Relationship to errors** | A workflow can be in this count while showing zero errors. Broken triggers fail silently; they do not raise error events. This is why a separate count is needed alongside the errors card. | | **HubSpot Hub scope** | All Hubs that support workflows (Professional and above). Starter portals without workflows show zero. | | **Currency** | n/a (count). | | **Time window** | `RT` (real time). The count refreshes as enrolment activity arrives. | | **Alert trigger** | More than zero blocked or stale workflows. | | **Roles** | owner, marketing, engineering. Marketing owns the automation logic; engineering owns property and list changes that break triggers; the owner watches it as an operational-readiness signal. | ## 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: | Workflow | Trigger type | Last enrolment | Likely cause | | ---------------------------- | ------------------------------ | -------------- | --------------------------------------------------- | | Brand-A loyalty tier upgrade | Property: loyalty\_tier change | 6 days ago | Property archived during loyalty-platform migration | | Brand-A back-in-stock notify | List membership | 3 days ago | Source list deleted | | Brand-B birthday club | Property: birthday\_month | 31 hours ago | Property rename to dob\_month | | Brand-B post-purchase review | Event: order placed | 28 hours ago | No orders in window (genuinely quiet) | What the team does with this before launching the sale: 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. Illustrative numbers only. ## 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: | Card | Why pair it with Workflows Blocked / Stale | | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | [Workflow Stopped Enrolling (>24h)](/nerve-centre/kpi-cards/hubspot/workflow-stopped-enrolling-24h) | The real-time alert version of this count. This card is the dashboard number; that one pings you the moment a workflow goes silent. | | [Workflows With Errors](/nerve-centre/kpi-cards/hubspot/workflows-with-errors) | The loud-failure sibling. A workflow can be stale (here) or erroring (there); together they cover both ways automation fails. | | [Workflow Error Spike](/nerve-centre/kpi-cards/hubspot/workflow-error-spike) | The rate-of-change companion on errors, useful for separating a sudden error storm from a quiet stall. | | [Workflow Enrollments (30d)](/nerve-centre/kpi-cards/hubspot/workflow-enrolments) | The volume baseline that tells you which workflows should never appear in this count. | | [Active Workflows](/nerve-centre/kpi-cards/hubspot/active-workflows) | The denominator. Stale count over active count is the automation-health ratio. | | [Top Workflows by Enrolments](/nerve-centre/kpi-cards/hubspot/top-workflows-by-enrolments) | Severity context. A top enroller showing up stale is a priority-one fix. | ## 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](https://app.hubspot.com/workflows) for the full list, sortable by some columns but not by last-enrolment staleness. > [HubSpot → Automation → Workflows → (workflow) → Enrollment history](https://app.hubspot.com/workflows) to read the last enrolment per workflow, one at a time. > [HubSpot → Settings → Properties](https://app.hubspot.com/settings) 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:** | Reason | Direction | Why | | ------------------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Staleness threshold tuning** | Our count lower | Workflows configured with a longer cadence tolerance are excluded until they exceed their own threshold, so they will not appear even after 24 hours of quiet. | | **Time zone** | Boundary effect | The 24-hour window is anchored to the portal's reporting time zone; a workflow that last enrolled just over the line can move in or out of the count depending on read time. | | **Disabled mid-window** | Our count lower | A workflow paused after going stale leaves the count because only enabled workflows are evaluated. | | **Low-frequency by design** | Either | Rare-trigger workflows look stale to a naive audit but are excluded here if marked low-frequency; the manual auditor may count them and the card may not. | | **Recent re-enable** | Our count lower | A workflow just re-enabled has its enrolment clock effectively reset and will not register as stale until it has had time to fail to enrol. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Flow Status Breakdown](/nerve-centre/kpi-cards/klaviyo/flow-status-breakdown) | If the merchant also runs Klaviyo, a shared upstream data change can stall automation on both platforms at once; watch both after any property or schema change. | The platforms reference fields independently, so one can stall while the other keeps running. | | [Form Submissions (30D)](/nerve-centre/kpi-cards/hubspot/form-submissions) | If form-triggered workflows are in the stale count while submissions continue, the trigger is broken, not the form. | If submissions themselves dropped, the stall is upstream of the workflow. | ## 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:** 1. Open the drill-down and sort stalled workflows by funnel value or normal enrolment volume. 2. For each, inspect the trigger for a renamed property, archived field, or deleted list. 3. Fix the highest-value workflows first; one shared dependency may clear several at once. 4. For genuinely low-frequency workflows, set an appropriate staleness threshold instead of fixing them. 5. Re-check before any major campaign and treat a non-zero count as a launch blocker. *** ### Tracked live in Vortex IQ Nerve Centre *Workflows Blocked / Stale* is one of hundreds of KPI pulses Vortex IQ tracks across HubSpot and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.