---
title: "What \"too many requests\" actually means, and what to do about it"
description: "Your app said \"too many requests.\" That's a speed limit, not damage. Here's how to find the cause and stop it happening again."
url: https://www.fomio.ai/blog/what-too-many-requests-actually-means-and-what-to-do-about-it
published: 2026-09-01T18:00:00.328+00:00
updated: 2026-09-01T18:00:00.328+00:00
topic: error-translation
words: 2001
---

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

Your app hit a speed limit, not a wall — here's how to tell the difference between a spike, a loop and an empty account.

**In short:**

- A service your app depends on decided it was being asked for things too quickly, so it said slow down. Nothing is broken and nothing is lost.
- Real speed limits reset by themselves, so wait a minute and try again before you change anything.
- If it failed suddenly and everywhere at once, check the balance on your paid services first — an empty account looks identical from the outside.
- The most common cause is something in your app asking for the same thing over and over in a loop.
- Because it comes and goes, you need something watching from outside to tell you it happened at all.

### What does "429 too many requests" mean?

It means a service your app relies on received too many requests from you in too short a time, so it refused politely instead of answering. The request itself was valid and the service is running fine. It is a traffic measure, not damage, and it usually clears on its own.

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[^1]. 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[^4]. 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[^2]. 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[^5].

### 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[^5]. 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[^3]. 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. **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[^1]. If it came back on its own, you have a spike or a loop, not a broken app.
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. **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. **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. **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.

**Paste this into your AI tool**

```text
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.
```

> **What this looks like to a user** — Not a dead site — a slow one, or one page that won't load while the rest is fine. SiteLock's write-up covers the same error from the site-owner side, and the pattern is consistent: intermittent, page-specific, and gone by the time you look[^6].

## 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.

*Tools that watch an app from outside, compared on what they ask of you*

| Tool | What setting it up asks of you | How it tells you | Best for |
| --- | --- | --- | --- |
| UptimeRobot | How often to check, which replies count as failures, where to send alerts | Email and other channels you configure | People comfortable answering those setup questions |
| Better Stack | The same questions, plus who to wake and in what order | Email, chat tools, phone calls | Teams needing checks from many countries and long records |
| Uptime Kuma | A server you run and maintain yourself, then all the same settings | Whatever you connect it to | People happy hosting their own software for free |
| Fomio | A link. It works out what to watch; there is nothing to configure | Email, in plain English, saying Working, Having trouble or Down | People who didn't choose their stack and don't want to learn it |

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.

## Questions people also ask


### Will waiting fix it on its own?

Usually, yes. A genuine speed limit resets after a set window, and many replies include a note telling you how long to wait before trying again — sometimes a number of seconds, sometimes a specific time[^1]. The exception is when the underlying problem is billing rather than traffic. OpenAI's guidance is explicit that retrying a quota or balance problem does not restore access[^3]. So wait once, and if it comes straight back, go and check the money.

### Is this the same as my app being down?

No. Down means nothing answers. This means something answered and said not right now. The service understood the request perfectly well and declined it on grounds of timing or volume[^4]. For a user the two can feel identical, which is why it is worth making your app say something human when it happens rather than showing a bare code. From your side, though, the fix is completely different: fewer requests, not repairs.

### Why does it only affect one page?

Because limits are counted per service, and different pages use different services. A page that pulls a list from your database, or asks an AI model for something, or sends an email, is spending from a different allowance than a page showing static text. If one screen is failing and the rest are fine, that screen is almost certainly requesting something in a loop — the retry storms Postman describes, where every failed attempt spends another request[^2].

### Could it be blocked before it even reaches my app?

Yes, and it's easy to miss. Protective services that sit in front of a site can return this response themselves when traffic pattern-matches to an attack, even when it's ordinary users[^5]. In that case your app never sees the request, so nothing in your own logs explains it. If you can't find any loop and your balances are fine, check whatever sits in front of your site before you keep digging through your code.

### How do I catch it next time?

Have something open your app from outside on a schedule and tell you when the answer changes. That's the only way to catch a problem that clears itself overnight. If you're comfortable choosing check frequencies and classifying responses, UptimeRobot or Better Stack will do it well. If you'd rather paste a link and be told in plain English that your app is Working, Having trouble or Down, that's what Fomio is for, and the free plan needs no card.


## Sources

[^1]: 429 Too Many Requests — HTTP — MDN Web Docs, Mozilla. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
[^2]: HTTP Error 429 (Too Many Requests) — How to Fix — Postman Blog (2025-11-21). https://blog.postman.com/http-error-429/
[^3]: How can I solve 429: 'Too Many Requests' errors? — OpenAI Help Center. https://help.openai.com/en/articles/5955604-how-can-i-solve-429-too-many-requests-errors
[^4]: HTTP Error 429: What causes it and how to fix it? — Network Solutions Blog. https://www.networksolutions.com/blog/http-error-429-too-many-requests/
[^5]: 429 Too Many Requests — What It Means and How to Fix It — Domain Monitor Blog. https://domain-monitor.io/blog/429-too-many-requests-fix/
[^6]: 429 Too Many Requests: What Is It & How to Fix It? — SiteLock. https://www.sitelock.com/blog/429-too-many-requests-error/