Your busiest week is when the automation gives up
The automation has been reliable all year. Then comes the week that pays for the quarter — the sale, the season, the campaign that worked — and it stops keeping up on the one day it matters.
This is not bad luck. Most integrations are limited by two different ceilings, and the one that catches you during a rush is not the one anybody looks at.
Two limits, and they fail differently
HubSpot publishes both, which makes it a useful example.
Its usage guidelines set a daily limit — 650,000 requests a day on Professional, a million on Enterprise — and a separate burst limit of 190 requests per 10 seconds, which applies on both. Public marketplace apps authenticating with OAuth get 110 requests per 10 seconds per HubSpot account, and the CRM Search API has its own burst limit of 5 requests per second. The daily allowance resets at midnight in your account's time zone.
Look at the shape rather than the numbers. The daily figure is enormous and, for a small business, nearly unreachable. The burst figure is small, and it is measured over ten seconds.
That is why the failure lands during your peak. Nothing about a busy week threatens a daily quota of 650,000. But a flash sale that lands two hundred orders in a couple of minutes, each triggering a workflow that reads a contact, updates a record and writes a note, produces exactly the density the burst limit is there to stop.
The limit that catches you is not about how much you did today. It is about how much you did in the last ten seconds.
What a 429 actually does
When you exceed the limit, the platform returns a 429 — and HubSpot's documentation notes it applies to all subsequent calls, not merely the ones over the line.
The important question is what your side does with that. There are three possibilities and they are very different for your business.
It waits and retries. The work is delayed and then completes. Fine.
It fails the run. The record is not processed. Whether it is queued for another attempt depends on settings that are frequently not switched on.
It fails silently. The workflow reports a run, the step that mattered did not happen, and nothing tells you.
The last case is the reason a busy week can end with everything looking normal and, three weeks later, a set of customers who never got a confirmation.
Everything else that gives at the same time
Rate limits are the mechanism people know. A seasonal peak tests several other things at once, and they tend to give in the same hour.
Plan allowances that count operations. If your automation platform bills by task or operation volume, a peak is when you discover the size of your monthly allowance. Running out mid-rush stops the work, not the sales.
Queue depth. A workflow that comfortably processes a record every few seconds will not catch up on a backlog of two thousand within the day, so "delayed" becomes "wrong" once customers start asking.
The slowest link. Chains run at the speed of their tightest limit, and it belongs to whichever service has the strictest rules — often not the one you think of as the main system.
Anything with a human in it. An approval step that works at ten a day does not work at three hundred, and nothing technical will report that as a failure.
What to do before the season, not during it
Find your real numbers. Take last year's peak day, or your best guess, and work out records per minute at the busiest hour. Compare that against the burst limits of each service in the chain. Most of the time this is arithmetic, not engineering.
Ask what happens on a 429. For each automation: does it retry, does it fail, does it queue? If nobody knows, assume the worst answer and test it.
Check your plan allowance against the month, not the day. A peak week consumes a disproportionate share of a monthly quota, and the rest of the month still has to run.
Spread what does not need to be instant. Not every step has to happen within seconds of the order. Confirmations do. Reporting, tagging and enrichment can run behind, and moving them off the critical path buys you headroom exactly when you need it.
Have a manual answer ready. Know which single thing you would do by hand for a day if the automation could not keep up — usually "send the confirmations". Deciding that in advance is much cheaper than deciding it at nine on the busiest morning.
After it happens
The clean-up matters more than the diagnosis, and it goes in this order.
Find out what did not happen rather than what errored: which orders lack a confirmation, which records never reached the accounting system. Errors are a symptom; the gap is the damage.
Then work out whether anything processed twice, because a retry that fired after a partial success is the other common outcome and it is more awkward to explain to a customer than a delay.
Then write down the numbers you actually hit. Next year's planning is much easier with one real data point than with any amount of estimating.
When headroom has to be designed in
For a business whose peak is a busy Saturday, the checks above are enough.
It changes when the peak is a genuine multiple — a seasonal business doing a third of its year in six weeks, or a campaign that lands everything in an hour. Then keeping up is a property of how the thing is built: what runs immediately and what runs behind, what gets retried and in what order, and what happens to the work that arrives while you are being throttled.
Working out which of your processes would survive four times your usual volume, and which would quietly drop things, is one of the things a process audit covers: $299, three business days, and an answer before the season rather than after it.
Sources
I read this page in August 2026. Limits and plan structures change; check the vendor's own documentation, and note that these are one platform's numbers rather than an industry standard.
Daily quotas, burst limits and the 429 behaviour: HubSpot's API usage guidelines and limits.
Related: when the other app says slow down, what happens to the records covers being throttled by a service you do not control, rather than hitting the ceiling of the one you pay for.