Real-time alert when an enabled workflow has not enrolled a single contact in over a day. Usually means the trigger criteria broke or a referenced property was renamed.
At a glance
Workflow Stopped Enrolling (>24h) is a real-time silence alert. It watches enabled workflows and fires when one that should be enrolling contacts has not enrolled anyone in more than 24 hours. A workflow can show no errors and still be quietly broken: if its trigger criteria reference a property that was renamed, a list that was deleted, or a value that no contact ever satisfies any more, the workflow stays “enabled” but stops doing anything. Because there is no error event, nothing else flags it. This card is the canary that catches automation that has gone silent before a campaign launches on top of a dead pipeline.
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 subscription skincare brand on Marketing Hub Professional runs several always-on workflows. Reading on 9 May 26. Last week an engineer renamed a custom contact property fromsignup_source to acquisition_source during a data-model tidy-up. Three of the brand’s workflows triggered off signup_source. They did not error, they simply stopped matching anyone. The card fires:
What the team learns:
- Three workflows went silent together, which points to a single root cause. When multiple workflows stop enrolling at roughly the same time, look for one shared dependency rather than three separate failures. Here it is the renamed property.
- The welcome workflow is the most expensive silence. It sits at the very top of the funnel; 41 hours of no welcome means every new subscriber in that window got no onboarding email. Those are first-impression moments that cannot be recovered.
- The cart-abandon workflow is healthy, which is the tell. Event-triggered workflows that fire off store activity kept enrolling normally, confirming the break is specific to the property-triggered workflows, not the whole automation engine.
- The win-back workflow is silent but not flagged, and that is correct. It triggers off
last_order_datecrossing a 90-day threshold, which only a handful of contacts hit on any given day. Nineteen hours of quiet is within its normal cadence, so the longer threshold configured for it keeps it from false-alarming. - The fix is a one-line trigger edit per workflow. Point the three broken triggers at
acquisition_source, re-enable, and confirm enrolments resume within minutes. The card clears once each workflow enrols again.
Sibling cards merchants should reference together
This alert is the silent-failure detector for automation. Pair it with these to cover the other failure modes and the volume baseline:Reconciling against HubSpot
Where to look in HubSpot: HubSpot shows per-workflow enrolment history but does not alert when a healthy-looking workflow quietly stops enrolling. The closest native views:HubSpot → Automation → Workflows and open the workflow, then the Enrollment history tab to see the last contact enrolled and when. HubSpot → Automation → Workflows → (workflow) → Performance for enrolment counts over time. HubSpot → Settings → Properties to confirm whether a property the workflow references was renamed or archived.The merchant traditionally finds a silent workflow only when someone notices the downstream emails stopped, which can be days later. This card surfaces the silence within a day. Why a flag may be expected rather than a real break:
Cross-connector reconciliation:
Known limitations / merchant FAQs
The workflow shows no errors in HubSpot. Why is it flagged? That is exactly the case this card exists for. A workflow with a broken trigger (renamed property, deleted list, an impossible criterion) does not throw an error. It simply matches nobody and enrols nobody. HubSpot’s error reporting stays clean while the workflow does nothing. Silence, not errors, is the signal here. One of our workflows only enrols a few people a month. Will it flag every day? It would, unless you tell the card it is a low-frequency workflow. Give such workflows a longer silence threshold in the profile, or exclude them, so the alert is reserved for workflows that genuinely should be enrolling continuously. We disabled a workflow on purpose. Will it flag? No. Only enabled workflows are evaluated. A paused or draft workflow not enrolling is expected and is ignored. How fast does the flag clear after we fix the trigger? As soon as the workflow enrols at least one contact again, its last-enrolment timestamp updates and the card clears on the next evaluation, usually within minutes once contacts start matching the corrected criteria. Multiple workflows flagged at once. Is that a bigger problem? Often it is one problem, not many. Simultaneous silence across several workflows usually points to a shared dependency that broke: a renamed property, an archived field, a deleted list, or a sync that stopped writing the value the triggers depend on. Look for the common thread before treating them as separate incidents. Does this measure enrolment or email sending? Enrolment. A workflow can be enrolling contacts but failing to send (that shows up as errors or in deliverability cards). This card is upstream of that: it confirms contacts are entering the workflow at all. No enrolment means nothing downstream can happen. Action playbook when this fires:- Open each flagged workflow and read its enrolment trigger.
- Check whether any property, list, or value the trigger references was recently renamed, archived, or deleted.
- If several workflows flagged together, find the shared dependency first; one fix may clear all of them.
- Repair the trigger, re-confirm it matches live contacts, and watch enrolments resume.
- For workflows that legitimately enrol rarely, set a longer silence threshold so they stop false-alarming.