Skip to main content

Confirm

Are you sure?

Changelog · September 8, 2026

A site that can't keep up is paced, not failed

A crawl of a small shop on shared hosting should finish, not fail 24 requests in a row.

By · Last updated: September 2026

TL;DR

When a site you're fetching times out, returns a 5xx or says 429, URLpipe now slows its requests to that site and tries again instead of reporting each one as a failure. Requests keep trying for up to 10 minutes from when they were accepted, so a batch against a small site takes longer rather than failing.

Free plan, no credit card. 1,000 credits a month.

A customer's crawl of a small shop failed 24 requests in a row with timeouts. The pages were fine a minute later; the shop's server had simply been overwhelmed. Requests to a struggling site now back off — the gap between requests grows with every stall and shrinks with every page served — and a request that hit a busy moment is retried instead of answered with a failure.

Only the failures worth waiting out are retried: a timeout, the site's own 5xx, and 429. A refused connection, a name that doesn't resolve, a bad certificate or a 404 is answered straight away, because waiting won't change it.

What you see is a slower request, not a failed one. A sync request may outlive its 60-second wait and answer with a token to collect later; an async one simply delivers later. You aren't charged for the wait.

FAQ

Frequently asked questions

How long will URLpipe keep retrying a slow site?
Up to 10 minutes from when the request was accepted. After that it answers with whatever the last attempt got.
Which errors are retried?
Timeouts, the target's 5xx responses and 429 Too Many Requests. Stable failures such as a 404 are answered immediately.
Am I charged for the waiting?
No. Credits are spent only on a result, and waiting on a paced site doesn't hold one of your parallel slots.

Try it on the free plan.

Free plan, no card. Confirm your email and your API key is live — you'll be making real requests in minutes.