Self-paced loop
- Industry term
A self-paced loop is a job that checks on something repeatedly and picks when to check next from what it finds. It stops once the work succeeds, fails, is cancelled, or runs out of time.
Each check returns a status the service defines, such as “queued,” “running,” “failed,” or “done.” While the job is unfinished, the loop usually waits longer after each check, so early checks catch quick jobs and a slow job isn't asked hundreds of times.
Where you’ll meet it
You ask your assistant to send a two-hour meeting recording to a transcription service. It asks the service for the status every few seconds. The service reports that the job failed, yet the assistant keeps waiting, and an hour later the chat is still spinning.
What to do
Tell the assistant that “failed” ends the job just as “done” does, and to give up after 30 minutes and tell you how it went. Two hours of audio won't be transcribed in seconds, so its first check can wait a minute.
Easy to mix up
| Self-paced loop | Cron schedule |
|---|---|
| Until the one job it's watching is over | Indefinitely, at the times it was given |
Check yourself
Your loop checks on a report export, and the service answers with an error that reads "Too many requests." What should the loop do?
Go deeperPolling is the fallback when a service can't announce that it's done
Repeated checking is called “polling.” When a service can instead contact your system the moment a job ends, through a webhook (a message it sends to an address you give it), nothing needs to keep asking. Polling stays useful for services that offer only a status check, and for catching a webhook that never arrived.
Growing the wait by a fixed multiple each time is called “exponential backoff.” Adding a little randomness to each wait, called “jitter,” keeps many programs watching the same service from checking at the same instant. The loop should also save its final status somewhere durable, so a crashed session doesn't lose the result.