HubSpot Deal Rotting Alerts: Native vs Custom

HubSpot deal rotting alerts are not really an alert feature at all, and that gap between the name and the mechanism is where most build-or-buy decisions on this go wrong. HubSpot calculates a stalled-deal timestamp natively; it does not notify anyone by default. This guide covers what the native mechanisms actually do, when they are enough on their own, and the specific gap that makes a custom build earn its cost rather than just feel more thorough.

HubSpot Deal Rotting Alerts: What Native Actually Does

HubSpot’s own default deal properties documentation defines an “Is Stalled After” timestamp: it is set automatically once a deal’s time in its current stage becomes 20% longer than the deal owner’s own closed-won average for that stage. The calculation itself, working out what “too long” means for a given owner’s typical pace, is the genuinely expensive part of a stalled-deal system to build from scratch, and HubSpot ships it as a property that populates on its own.

What that property does not do is act on itself. It is a timestamp on a record, available to filter, list, or build a workflow against, but nothing happens automatically just because the property is now populated. A deal can sit stalled for weeks with the timestamp quietly set and nobody notified, if nothing downstream is built to check it.

HubSpot ships a second native mechanism worth naming here, since it is what most people actually picture when they hear “deal rotting”: a configurable card-inactivity setting on the pipeline board view, which HubSpot’s own board-view documentation describes as highlighting a deal card as inactive once it passes a set number of days, for example fourteen, without activity. This is a genuine setting a team can find and adjust, unlike the calculated timestamp, but it produces a visual highlight on the board, not a notification to anyone.

A team evaluating whether HubSpot “handles” stalled deals natively will reasonably expect to find a working alert somewhere in the settings, and the closest thing to that is this highlight: a real, findable setting that still notifies nobody unless someone is actively looking at the board.

A Signal, Not a System

This is the gap the feature’s own name obscures. “Deal rotting alerts” implies something that pings a rep; what actually ships is a calculated signal a team still has to wire into an action. Turning it into a genuine alert means building a HubSpot workflow that enrols on the stalled property being set and sends a notification, at minimum, which is a real but modest piece of configuration rather than a native alerting system working out of the box.

Framing the decision as “native versus custom” as a single binary misses this. The genuinely expensive part, the calculation itself, is already built. The build-or-buy decision most teams actually face is narrower: native property plus a workflow, versus native property plus a workflow plus specific custom logic for whatever the native version gets wrong for this particular business. Scoping a custom build to exactly what is missing, rather than replacing the whole mechanism, is both cheaper and less likely to introduce a new, worse version of the same calculation HubSpot already got right.

When Native Plus a Simple Workflow Is Enough

For a sales team where deals sharing the same pipeline and the same owner move through a reasonably consistent cycle length, the native property plus a basic enrolment workflow covers the actual requirement. A team that mainly wants a visual cue when a deal has gone quiet, rather than a calculated timing baseline, may prefer the board-card inactivity highlight covered earlier instead, though it still only surfaces on the board rather than notifying anyone directly.

The per-owner, per-stage baseline HubSpot uses is a genuinely reasonable default when a business does not have wildly different deal shapes competing for the same calculation within one pipeline and one rep’s book, and building anything more sophisticated on top of an already-adequate signal is effort spent solving a problem the team does not actually have.

This covers a larger share of teams than the “native is basic, custom is better” framing usually implies. A team that has never actually audited whether its own deals genuinely vary enough within a single pipeline and owner to justify a segmented calculation is more likely to be guessing that a custom build is necessary than to have properly confirmed it, and the honest first step is checking that underlying assumption directly before committing engineering time to building around it.

A quick way to check the assumption without building anything is to pull time-in-stage for closed-won deals over the last two quarters, grouped by owner and by stage since that is how the native baseline is already scoped, and look at the spread within each owner’s own history for that stage, not just the average. A tight spread, where most of one rep’s deals close within a broadly similar window regardless of size or type, means the single blended baseline the native property already calculates is a reasonable fit as it stands.

A wide spread within a single owner’s own deals, where the fastest and slowest sitting in the exact same stage differ from one another by weeks or even months, is the concrete signal that a properly segmented approach is genuinely worth the build effort, rather than a general instinct that more sophistication must automatically be better.

When a Custom Build Earns Its Cost

The specific gap worth building around is the time-in-stage baseline itself, not the inactivity highlight covered above. The calculated “Is Stalled After” timestamp is worked out per deal owner, against that owner’s own closed-won average for the current pipeline stage, so two deal types running through separate pipelines already get separate baselines, and so do two deal types handled by different reps within the same pipeline. What it does not do is separate deal types that share both the same pipeline and the same owner.

A business where the same reps carry both self-serve and enterprise deals through one shared pipeline, so the owner axis cannot separate the two deal types either, gets one blended baseline per stage that is wrong at both extremes: the self-serve deal flagged too late to matter and the enterprise deal flagged as stalled when it is simply moving at its normal, longer pace. That mismatch, not a general preference for more sophistication, is what actually justifies a custom, segmented calculation.

HubSpot’s own documentation on setting up and customising pipelines shows each pipeline already carries its own independent set of stages, and since the stalled baseline is calculated per stage, splitting genuinely different deal types into separate pipelines is itself a native answer to segment variation: a self-serve pipeline and an enterprise pipeline already get their own baselines. What that structure does not solve is one pipeline where the same reps carry more than one deal type. That narrower case, checked with the spread test above, is the specific piece worth building custom logic around.

Beyond segmentation, the fallback and escalation layer, what happens after a deal is flagged, is a separate design problem this article deliberately does not re-cover in depth. Blending time-in-stage with engagement recency rather than relying on a single signal, triaging a genuinely stalled deal from one that is simply dead, and keeping any automated action auditable rather than silent are all real design questions worth their own dedicated treatment. Anything built past the segmentation fix described here belongs in that separate design space rather than being reinvented from scratch in this comparison.

Where This Decision Usually Goes Wrong

The most common mistake is skipping straight to a custom build without first configuring the notification workflow the native property needs. A team that assumes the native feature is “too basic” often has not yet turned it into a working alert, since the property alone produces nothing visible. Building the simple workflow first, even for a team that expects to need something more sophisticated eventually, is worth doing anyway: it establishes a working baseline to compare a future custom build against, and it may turn out to be sufficient once it exists rather than being judged insufficient in the abstract.

The second common mistake is building a custom stalled-deal calculation that duplicates the native property’s core logic instead of extending it. A custom system that recalculates time-in-stage against a closed-won average from scratch, without segmenting by anything the native version does not already handle, has spent real engineering effort reproducing a calculation HubSpot already runs for free. The custom work only earns its cost at the specific point where it does something the native property cannot, which in most cases is exactly the segmentation gap this article covers, not a wholesale reimplementation of the underlying timing logic.

A useful discipline before writing any custom calculation is listing exactly which native behaviours are being kept and which are being replaced, since a build that cannot answer that question clearly is at real risk of quietly reproducing the whole native mechanism under a different name, at several times the maintenance cost of the property HubSpot already maintains.

Related Reading

For the CRM foundation this kind of build sits on top of, see HubSpot Consultancy. For the strategy layer above the platform itself, see RevOps Consultancy. On the broader pipeline discipline this fits inside, Automated Pipeline Hygiene covers the wider data-quality practice, and Automated Deal Stage Forecasting With n8n covers a related use of deal-stage timing data.

Go deeper: RevOps Automation Maturity Model · n8n vs Zapier for RevOps Automation

Book your free audit

Frequently Asked Questions