When All You See Is "An Error Occurred": Suspect a 429 First, and Check in This Order

I was polishing the store descriptions of one of my wallpaper apps in several languages one evening. I handed a task to the agent, stepped away, and came back to a screen that said only "An error occurred." No reason, no hint at a fix.

At first I read that sentence as "something broke." I restarted the app, reopened the project, and sent the same request three times. It didn't go well. Before the fourth attempt I finally stopped and opened the log, and found that nothing was broken at all. I had simply hit a usage limit.

Here is the point I most want to pass on: behind a generic error with no stated cause, there is sometimes a usage limit (HTTP status code 429). If that's what you're facing, there is nothing to repair. What you need is to wait, and to stop pressing the button.

Why a generic error and a 429 look the same

A 429 means "too many requests in a short time." The service is temporarily refusing to accept more.

Ideally the screen would say so plainly. In practice, the wording you see doesn't always mirror what happened behind it. A limit response, a failed connection, and an expired sign-in can all be folded into the same "An error occurred."

That's what makes the first step so confusing, I think: the message alone can't tell you which one you're dealing with.

Four checks, lightest first

Poking at settings at random tends to cost more time than starting with the cheap checks. Here is the order I use.

1. Look near the error for a "details" or "debug info" button.
2. In whatever it shows, search for 429, RESOURCE_EXHAUSTED, quota, or rate limit.
3. Send one very simple request (just "hello") and see whether it goes through.
4. Open the usage screen and see whether you're close to your limit.

Screen names and locations change between versions, so please treat this as a way of thinking: if there's an entrance to details near the error, look there first.

1. Open the details and search, don't read

A long block of technical text is hard to read when you're already frustrated. So don't read it. Search it.

Use your editor's or browser's find feature and try these terms one at a time:

429
RESOURCE_EXHAUSTED
quota
rate limit
exceeded

If any of them turn up, a limit is the likely cause. If you find 401, 403, expired, or unauthorized instead, the suspect is your sign-in state. If you find timeout, ECONNRESET, or network, it's the connection.

Whatever you find decides the next move.

2. Send one simple request, once

Some versions don't let you open details. In that case, send a short request exactly once.

Something like "reply with hello" is enough. If you get an answer, your account and connection are alive, which strengthens the reading that you touched a limit partway through a long job.

The word that matters is once. Start hammering the button here, and you fall into the trap in the next section.

What not to do: mashing retry, or automating it

Sending the same request again and again while you're at a limit can lengthen the wait. Some services count the retries that were refused and push back the time when they'll accept you again.

I lost time to this myself. The work was urgent, so I resent the request every time I came back to the desk, and ended up with half a day in which nothing moved.

My rule now:

When refused, press less often and wait longer.

In practice that looks like this:

• Make the first retry after a few minutes, and only once.
• If it's the same, double the gap and try once more.
• If it fails three times in a row, switch to other work for the day, such as research you can do locally or drafting text.

Deciding in advance what you'll work on while you wait makes the whole thing much easier on the nerves.

Once you know it's a limit

Two questions are worth asking.

First, what burned through the allowance? Handing the agent a huge file all at once, running several agents side by side, regenerating the same question over and over — if you recognize one of these, you can split or thin it out next time.

Second, is there an option other than waiting? Your plan's ceiling, a switch to a different model, or moving the work to tomorrow. Which one makes sense depends on how heavy the deadline is.

As an indie developer, I've found it helps to run non-urgent jobs early in the day and keep headroom for the urgent ones. Since I stopped queuing heavy requests in bulk at night, I've met the generic error less often.

When it wasn't a limit

If your search finds nothing about 429, the cause lies elsewhere.

When nothing turns up, I try not to force a cause. I write down that I don't know, so I can compare notes the next time the same symptom shows up.

Your next step

The next time you see a generic error, open the details and search for 429 before you restart anything.

That one move tells you whether something is broken or whether you only need to wait. I picked it up myself not long ago, and it has shortened the time I spend panicking in front of the screen, if only a little.