Limits and the Circuit Breaker
Extensions run under limits, and the platform will disable one that misbehaves. Understanding both is what makes running custom code safe.
Where to find it
Architect Panel → Automation:
- Extensions — the extension registry, its versions and runs
Architect Panel → Activity:
- Error Log — extension failures
Architect Panel → Security:
- Permissions — who may register or change an extension
The limits
- Timeout — how long a run may take.
- Memory — how much it may use.
- HTTP hosts — an allowlist of what it may call out to.
- Maximum mails per run — a cap on how much it may send.
- Run mode and fail mode.
The HTTP allowlist is the one to think about
An extension can only reach hosts you have listed. That is a genuine security boundary rather than a convenience: without it, custom code can send your data anywhere, and nothing about the rest of your configuration would prevent it.
List the specific hosts an extension needs. A permissive entry defeats the control entirely, and it is the kind of thing added during debugging and never removed.
The mail cap prevents a specific disaster
An extension in a loop that sends e-mail will send thousands before anybody notices, to real people, from your domain. The cap bounds that to something survivable.
Set it to a little above what the extension legitimately needs, not to a comfortable round number.
Fail mode decides what happens when it breaks
Whether a failing extension stops the operation it was attached to, or is skipped so the operation continues.
Neither is universally right. An extension performing an essential validation should fail closed — better to refuse than to proceed unchecked. One enriching a record with something optional should fail open, because a broken extension should not stop people working.
Decide per extension, deliberately. The default will be wrong for half of them.
The circuit breaker
The platform tracks invocations, failures and consecutive failures over a window. An extension failing repeatedly is tripped — automatically disabled — and periodically probed to see whether it has recovered.
This is why a broken extension is a contained problem rather than a rolling one. Without it, something failing on every record would keep being called, keep failing, and keep consuming resources indefinitely.
A tripped extension is telling you something
Do not simply re-enable it. It tripped because it failed repeatedly, and re-enabling without fixing the cause produces the same trip and a longer outage of whatever it does.
Read the error log, fix the cause, then let it recover.
Disabling is recorded
An extension carries who disabled it, when and why — so a disabled extension is explicable rather than a mystery for whoever finds it next.
Worked example
A supplier integration extension is allowlisted to one host, capped at five e-mails per run, and set to fail open so a supplier outage does not block order entry. When the supplier had a bad afternoon the breaker tripped after repeated timeouts, order entry continued unaffected, and the error log showed exactly why.
Recommendations
- Allowlist specific hosts, never something permissive.
- Choose fail mode per extension — the default is wrong half the time.
- Never re-enable a tripped extension without fixing the cause.
- Set the mail cap just above genuine need.