The Hidden Costs of DIY Custom Code Actions in HubSpot

Custom code actions inside HubSpot workflows look like the cheapest automation you will ever build. A free-text code window sits right there in the workflow editor, your team writes a few lines of Node.js, and a job that brittle middleware could never quite handle is suddenly done in an afternoon. No new vendor, no procurement, no engineering ticket.

That first win is real. The trouble is what it hides. A custom code action is a tiny piece of production software running against your CRM, and most of the cost of production software shows up months after the code is written. This is a decision-stage view of where those costs land, so you can judge for yourself whether writing and owning this code in-house is the right call, or whether the smarter move is to buy in the engineering expertise.

The 20-second wall is a hard wall

HubSpot's documentation is unambiguous: a custom code action must finish running within 20 seconds. It is a system-wide limit and you cannot change it. The action also runs in a constrained sandbox: up to 128 MB of memory, with the total length of all your secret values capped at 1000 characters. Those numbers come straight from HubSpot's custom code actions reference.

For a quick field calculation or a lookup against a fast endpoint, 20 seconds is plenty. The problem is anything that touches a slow third-party API, a system under load, or a payload that needs several round trips. The moment your call takes 21 seconds, the action fails. There is no async escape hatch in the in-line editor. You cannot tell HubSpot to pause and come back later.

There is a pattern for long-running work, but it is worth being precise about it because teams routinely conflate the two. HubSpot supports a callback model where an action returns a BLOCK state, offloads the work to an external service, and resumes when that service calls back (HubSpot will wait up to a week by default). That mechanism belongs to custom workflow actions built via the Automation API, the public-app and extension route, not the Custom code action you type into the workflow editor. In the editor, 20 seconds is the end of the conversation.

This matters commercially because outgrowing the editor is not a tweak. It pushes you into building and hosting a proper external service, which is a software project with its own infrastructure, deployment and monitoring. That is exactly the line where a build-in-house decision quietly becomes a build-and-maintain-forever decision.

Retries are automatic, but they are blind

HubSpot will retry a failed action for you. If you surface the error correctly (throw it in the catch block in Node.js, or raise it in the except block in Python), HubSpot will reattempt your action for up to three days, starting a minute after the failure. That sounds like a safety net, and it is, until you think about what a retry actually does.

A retry re-runs your code from the top. If your action created a deal, sent an external API call, or triggered a payment on its first attempt, and only failed on a later step, the retry does all of that again. Unless your code is idempotent (built so that running it twice produces the same result as running it once), you get duplicate records, double-fired side effects, and in the worst cases double charges. HubSpot retries the action; it does not protect you from the consequences of running it twice. Idempotency is your team's responsibility, and it is one of the most commonly missed requirements in DIY code.

Silent failures are the expensive kind

Error handling in this environment has a sharp edge. If your code does not throw or raise on failure, HubSpot does not retry and does not flag a problem. The action quietly reports success while doing nothing. There is no built-in alerting to tell you a workflow has been silently dropping records.

So failures do not announce themselves. They surface weeks later as a sales rep asking why a segment of contacts never got enriched, or a finance query about records that should exist and do not. By then the trail is cold and the cleanup is manual. The cost was never the code; it was the gap between the failure and the day someone noticed.

Secrets and security are a governance question

Your credentials live in the action as environment variables. There is no real secrets-rotation tooling, and that 1000-character total cap on all secret values is easy to trip over once you are integrating with more than one system. More importantly, API keys embedded in workflow code, scattered across a HubSpot portal with no version control, is a genuine governance concern. For any business that takes security seriously (and certainly anyone holding a standard such as Cyber Essentials Plus), "where do our integration credentials live and who can see them" is a question you want a clean answer to.

The maintenance debt nobody budgets for

This is the cost that dwarfs all the others, because it never stops accruing. Custom code actions run on a limited, version-pinned set of libraries, and the Python runtime is documented as beta. Your code is not in a repository. There is no test suite. There is no review process. And critically, there is no single owner: code ends up scattered across dozens of workflow actions, each written by whoever needed it that week.

Then the person who wrote it leaves. The knowledge walks out of the door, and what remains is a portal full of undocumented logic that nobody fully understands and nobody dares change. Every HubSpot platform update, every API version bump, every new requirement becomes a small archaeology project. The afternoon you saved at the start gets paid back many times over.

It is also worth remembering this automation is not free in the first place. Custom code actions require Data Hub (formerly Operations Hub) Professional or Enterprise, per HubSpot's guidance on choosing workflow actions. You are already paying for the privilege of writing the code; the maintenance is on top.

When to build, and when to buy the expertise

None of this means custom code actions are wrong. For small, self-contained, idempotent jobs that comfortably fit inside 20 seconds, they are a perfectly good tool and we recommend them. The question is whether the work you have in mind actually fits that box, or whether you are about to take on a hidden software-maintenance liability.

The honest test is this. If the job needs to talk to a slow external system, must never run twice, holds sensitive credentials, or is important enough that a silent failure would cost you real money, it has outgrown the editor. At that point you are building external infrastructure, and the right home for it is properly engineered, version-controlled and owned. That is the difference between a workaround and a system you can trust.

SpotDev is the software engineering firm for HubSpot customers. We build custom-coded workflow actions (from £2,500) and serverless functions (from £2,000) that are engineered to last: idempotent by design, properly monitored, secrets handled correctly, and documented so they survive a team change. As a UK HubSpot Diamond Partner with in-house engineers, we own the maintenance debt so your team does not. If you are weighing up whether to write this in-house or hand it to a team that does it every day, that is exactly the conversation our HubSpot development practice exists for. Request a quote and we will tell you, straight, whether your job belongs in the editor or in a real service.

If you want to understand the broader picture first, our guide to what you can build with custom HubSpot development is a good place to start.

Frequently asked questions

What is the execution time limit for a HubSpot custom code action?

Custom code actions in HubSpot workflows must finish running within 20 seconds. This is a system-wide limit that cannot be changed, and there is no asynchronous escape hatch inside the in-line workflow code editor. Anything that takes longer fails outright. Work that needs more time has to be offloaded to an external service, which is a separate engineering project rather than a workflow tweak.

Does HubSpot retry a custom code action if it fails?

Yes. If you surface the error correctly (throw it in the catch block in Node.js or raise it in the except block in Python), HubSpot reattempts the action for up to three days, starting one minute after the failure. The catch is that retries re-run your code from the top, so unless your code is idempotent you risk creating duplicate records or firing side effects twice.

What is idempotency and why does it matter for custom code actions?

Idempotency means your code produces the same result whether it runs once or several times. Because HubSpot retries failed actions automatically, code that is not idempotent can create duplicate deals, duplicate external API calls, or even double charges when a retry re-runs steps that already succeeded. Building idempotency in is the developer's responsibility, not something HubSpot handles for you, and it is one of the most commonly missed requirements in DIY code.

Do custom code actions require a paid HubSpot tier?

Yes. Custom code workflow actions require Data Hub (formerly Operations Hub) Professional or Enterprise. So this form of automation is not free, and that subscription cost sits on top of the engineering and ongoing maintenance effort involved in writing and owning the code.

When should we use a serverless function instead of a custom code action?

When the work outgrows the workflow editor: longer-running tasks, anything that needs proper version control, monitoring and a clear owner, or logic too important to risk a silent failure. HubSpot serverless functions have their own constraints (a 10-second per-function limit and 128 MB of memory, distinct from the 20-second custom code action limit), so the right choice depends on the job. A HubSpot development specialist can advise on which fits.