Skip to main content
Metrics type: Key Metrics • Category: Email Marketing
Surge in failed workflow actions, usually a deleted property or unpublished email. Audit HS02 cross-fires.

​
At a glance

Real-time anomaly detector for workflow errors. Fires when 24-hour error volume exceeds 2 standard deviations from the trailing 7-day baseline. Most-common causes: a deleted property, an unpublished email referenced by a workflow, a removed list trigger, or a send-from address that lost verification.

​
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

The same B2B SaaS portal with 38 active workflows. The 7-day baseline: Reading on 14 Apr 26 morning: Five things this picture reveals:
  1. 9.7σ is far above the 2σ threshold; the spike is unambiguous. The audit log shows the property-delete event happened at 16:42 yesterday, just before close-of-business; the next 16 hours of trial-expiry enrolments all failed at the delay step that referenced the missing property. Audit HS02 fired at 17:38 yesterday once the delay-step backlog hit 1.5σ.
  2. The Trial Expiry Nurture workflow alone accounts for 142 of 222 errors (64%). Single-cause spikes are easy to fix; multi-cause spikes (errors evenly distributed across workflows) usually mean a portal-wide change (auth refresh, integration timeout, bulk-import overrun).
  3. The “Welcome step 2” unpublish (58 errors) is a different cause but coincident. A marketer was redesigning the welcome series and accidentally unpublished a step. Vortex IQ shows both as contributors. The workflow does not pause; it errors on each enrolment until the step is republished.
  4. Steady-state errors (22) are normal noise. Each portal has a baseline of INVALID_EMAIL_ADDRESS errors from typo’d form submissions; these are expected and contribute to the 7-day mean. They do not cause spikes; only deviations above baseline do.
  5. Recovery is automatic once the cause is fixed. Re-creating trial_end_date (or pointing the workflow at a renamed equivalent) and re-publishing the welcome step both stop new errors. The 24h trailing count decays over the next 24 hours and falls below the threshold; the alert clears on the next evaluation cycle.

​
Sibling cards merchants should reference together

Workflow Error Spike is the leading indicator. Pair with downstream cards to confirm impact:

​
Reconciling against the vendor’s own dashboard

Where to look in HubSpot: Two native views cover the spike’s components:
HubSpot → Automation → Workflows (filter to “Errors” facet, sorted by recency) HubSpot → Automation → Workflows → individual workflow → History tab (per-workflow event log)
The error-recency facet should show the same workflows in this card. Why our number may legitimately differ from HubSpot’s: Cross-connector reconciliation:

​
Known limitations / merchant FAQs

The alert fired but the dashboard says zero workflows in error, why? The alert fires on a 24h spike; by the time the merchant looks, errors may have been fixed. Check the audit log for the original event time. The Workflows With Errors card retains the rolling 7-day list for follow-up. What is the difference between this card and Workflows With Errors? This card detects sudden change (a spike vs baseline). Workflows With Errors is the persistent list (any errored workflow in the last 7 days). Use both: the alert tells you something just broke; the list tells you what is still broken. Can I tune the 2σ threshold? Yes, configurable per portal. Tighter thresholds (1.5σ) catch more anomalies but increase false positive rate. Looser (2.5σ) only catches major events. 2σ is the default for most B2B portals. Why does the alert clear before I have time to act? If the underlying error is fixed quickly, the 24h trailing count decays below the threshold. We do not auto-suppress; the audit log retains the alert fire-and-clear sequence. For long-running incidents, the alert stays active until the cause is fully resolved. INVALID_EMAIL_ADDRESS spikes, what do they mean? A campaign or import dumped many bad emails into a workflow. The workflow itself is fine; the data is not. Fix is upstream form validation or import-deduplication. RATE_LIMIT_EXCEEDED, what causes that? HubSpot’s automation API has per-portal rate limits. Bulk operations (mass imports, mass workflow re-enrolment) can spike errors briefly. Usually self-resolves within an hour. Multi-portal aggregation, can I see spikes across portals? No. One card per portal because the 7-day baseline is portal-specific. Aggregating across portals would dilute high-signal alerts on small portals. List-segment lag, can it cause a spike? Indirectly. A list-trigger workflow that mass-enrols based on list membership can cause a brief RATE_LIMIT spike during the enrolment-batch window. Usually self-resolves. Lifecycle-stage backfill, does it touch this? Lifecycle backfills that trigger downstream workflows (e.g. MQL handoff) can cause transient spikes. The alert may fire during the backfill window and clear once it completes. Audit HS01 surfaces backfill-triggered spikes separately. Today-volatility, why is the count higher in business hours? Workflows enrol contacts most actively during business hours (forms submitted, sales activities logged). Errors scale with enrolment volume. The 7-day baseline captures the bimodal hourly pattern, so business-hour error counts are expected.

​
Tracked live in Vortex IQ Nerve Centre

Workflow Error Spike 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 or book a demo to see this metric running on your own data.