What "too many requests" actually means, and what to do about it

Your app is showing something like "Too many requests." Or a spinner that never stops. Maybe a user emailed you. Maybe you found it yourself and your stomach dropped.

Mozilla's developer reference, which is the closest thing the web has to a dictionary for this, describes it exactly that way: too many requests in a given amount of time, and the practice of enforcing that is called rate limiting¹. The server is not confused. It is not down. It understood you perfectly and chose to say "not right now."

That distinction changes what you do next. Network Solutions puts it neatly: with this one, the request may be perfectly valid — the timing or the volume is the problem⁴. Compare it with the other error screens you have met. One means the thing you asked for does not exist. Another means you are not allowed. This one means you are allowed, it exists, you're just going too fast.

Why did my app suddenly hit a limit?

Almost every service your app touches counts how often it is asked for things. Your database, your login system, whatever sends your emails, whatever handles payments, the AI model behind your app if you have one. Each has a ceiling, and each counts separately.

You didn't set those ceilings and you almost certainly never saw them. The tool you built with picked the services, wired them together, and the limits came along in the box.

Something is asking in a loop

This is the most common cause and the least obvious. A page that fetches the same data every time it redraws. A retry that fires the instant a request fails, then fails again, then fires again. Postman's guide names this directly: apps that immediately retry failed requests create retry storms that make the problem worse, because every retry spends another request from your allowance². The app spends its whole budget arguing with itself, then a real user shows up and gets the door slammed.

Real people arrived

You posted somewhere. Someone shared it. Traffic that felt like a dream on Monday is exactly what a ceiling designed for a quiet app was not expecting. Domain Monitor makes the point about the settings themselves: a limit of ten requests a minute might be sensible for one kind of service and far too low for another, and rules that are too aggressive catch legitimate users in the crossfire⁵.

A protective layer in front of your app got twitchy

Domain Monitor also notes that services sitting in front of your site — Cloudflare, AWS and similar — can return this error when traffic looks like an attack even when it isn't⁵. Your app never sees the request at all. Something upstream decided on its behalf.

You ran out of money, not requests

This one looks identical from the outside and behaves completely differently. OpenAI's help page says the same error can mean a temporary limit, an exhausted prepaid balance, or a spending limit you set — and that retrying a billing or quota problem does not restore access³. Waiting will not help. If your app has an AI feature and it started failing everywhere at once, check the balance before you change a single line.

How do I fix too many requests?

Work through these in order and stop when the answer appears. Most people find it in the first three.

1. 1
   Find out whether it clears by itself

   Wait a minute or two and try again. Real speed limits reset. Many replies include a note saying how long to wait before trying again — MDN calls it the Retry-After header, and it does exactly what it sounds like, sometimes in seconds, sometimes as a specific time¹. If it came back on its own, you have a spike or a loop, not a broken app.
2. 2
   Check whether it is everyone or just you

   Ask someone on a different network to open it, or use your phone with wifi off. Many of these limits are counted per internet address. If it works for your friend and not for you, you personally have been slowed down — usually from hammering refresh at your own app, which is a very normal thing to do when you're worried.
3. 3
   Check the money

   Every paid service your app touches. Balance, spending caps, plan limits. Do this before anything else if the failure was sudden and total.
4. 4
   Go looking for the loop

   If it isn't billing and it isn't a one-off spike, something in your app is asking too often. You don't need to read the code to describe the problem — tell the tool you built with what you saw, in your own words.
5. 5
   Make it fail gently

   Whatever the cause, an app that hits a ceiling should tell the user something human — "we're busy, give it a second" — and try again after a short pause rather than instantly. The instant retry is what turns a small problem into an outage.

On the [screen name] page, my app is getting a "too many requests" response from one of the services it calls. It recovers after a minute or two of waiting. Find where this page is requesting the same data repeatedly and stop the loop. Then make failed requests wait a few seconds before retrying instead of retrying immediately, and show the user a friendly "we're busy, try again in a moment" message instead of an error code.

Why do I keep missing it when it happens?

Because this particular failure comes and goes. It hits during your traffic spike at 11pm, clears by the time you look at 8am, and you find nothing. Or it hits one page and not the others, so it works perfectly every time you check.

So the real question isn't how to fix it. It's how you find out it happened at all, before a user tells you. The answer is something outside your app that opens it regularly and tells you when the answer stops being normal.

Which tool should watch my app for me?

There are a good number of these, and they are not all built for the same person. The honest split is between tools that expect you to know your own infrastructure and tools that expect you don't.

Be clear about the trade. Fomio checks from outside and tells you by email — not by text message, not in a chat app. If you need to be phoned at 3am, or need checks from a dozen countries, or need records going back years, the engineering-first tools are genuinely better at that and you should use them.

What Fomio does instead is remove the vocabulary. It reports one of three things about your app — Working, Having trouble, or Down — and when something goes wrong it says in plain language what likely happened. On the paid plans it writes the prompt to paste straight into the tool you built with, which is the step that usually costs the most time when you don't know the words.

The free plan watches one app, checks it every five minutes, emails you when it breaks and keeps seven days of history, with no card needed. Builder watches three apps, checks every minute, keeps 30 days and writes the fix prompts. Pro watches 15, adds a public status page your users can check themselves, and keeps a year. Current prices are on fomio.ai/pricing.

What should I do right now?

You hit a speed limit, not a wall. Wait a couple of minutes, check the balance on your paid services, then look for the thing in your app that's asking too often.

And if you found out about this from a user rather than from your own app, fix that second. It's the difference between a bad ten minutes and a bad week.