What is a rate limit?

What it is, in plain words

Think of a bank counter that serves each customer a set number of times per hour. Come back within the hour and the clerk says, politely, “not yet”. Your request is fine. You have simply used up your turns.

That is a rate limit. Almost every service an automation talks to has one: social platforms, email senders, spreadsheets, CRMs, AI providers. The service counts your requests in a time window, and past a certain number it refuses the rest until the window resets.

A few words you will hear around it:

• Request or call: one message your automation sends to the service (“post this”, “read that row”).
• Quota: the number of requests allowed in the window, per minute, per hour or per 24 hours.
• Throttling: the service slowing you down or refusing you because you went over.

Related, but separate, are caps on size (for example, a maximum number of images in one post) and spending limits on paid accounts. They all stop a working automation for reasons outside its code.

A concrete example

I run a scheduled job that publishes posts to a social platform through its official interface. One post with several images is not one request. It takes roughly 80 calls to upload each piece, check it and publish it.

For a while the publishing slots were bunched into one part of the day, which was also the time of day I used the same interface myself. The platform started refusing with “application request limit reached”. The fix was not in the code. I spread the slots across the whole day and night so the same number of calls landed in a quieter window.

Three more things I learned from the same job:

• Retrying makes it worse. Every retry is another request against the same limit. My job now stops the slot immediately on a limit error instead of trying again.
• A refusal is not always a failure. On two days in August, five posts were recorded as failed after limit errors. All five had actually been published. The job now checks the account for the post before treating anything as failed, because publishing it again would create a duplicate.
• Sleep can cause a burst. When the computer running the job slept through its night slots, the work could run all at once on waking, which risks hitting the limit again. Keeping it awake for scheduled slots avoids that.

The same account has other caps: a daily maximum number of posts, and a maximum of ten images per post, which is why one of my designs had to drop an eleventh image. Separately, one of my overnight AI jobs once hit a monthly spending limit on its account. It produced its output, then ended with an error.

Why it matters when you hire someone

You will not configure limits yourself, but they shape how the automation should be built, and a demo will not show them. One test run uses a handful of requests. A real month of runs uses far more.

1. The limit belongs to your account. If the automation runs on your accounts, as it should, the limits of your plan apply. Your own other tools, or a second automation, may share the same quota.

2. Volume changes everything. An automation that is fine at ten items a day can fail at two hundred. Ask for the numbers at the volume you expect, not the volume in the demo.

3. Behaviour after a refusal is a design choice. Wait and continue, stop and alert, or hammer the service. Only the first two are acceptable, and which one is right depends on the task.

4. “Failed” may not mean “didn’t happen”. For anything that sends, posts or charges, the automation must check whether the action went through before retrying, or you get duplicates.

This is the rate-limit version of the silent and not-so-silent failures the acceptance checklist for unattended automations is built around. Limits are also a reason to agree maintenance terms up front: a plan change or a jump in volume can bring a limit into play months after delivery.

What to ask the freelancer

Add these to the “Failure behaviour” field of the workflow automation brief:

A good answer names the limits, gives a rough request count, and describes a retry that waits instead of hammering. If the answer is “it has never hit a limit”, ask at what volume it was tested.