# O Que É um Erro de Rate Limit? Explicação

> Um erro de rate limit significa que um serviço está rejeitando requisições porque você enviou demais rápido demais. Aprenda por que a CI atinge rate limits e como backoff e retries ajudam.

Source: https://latchkey.dev/pt/learn/ci-explained/what-is-a-rate-limit-error  
Updated: 2026-06-26

Um erro de rate limit significa que um serviço está deliberadamente rejeitando suas requisições porque você excedeu o número que ele permite em uma janela, comumente retornado como HTTP 429.

Para se protegerem, serviços limitam quantas requisições um cliente pode fazer por unidade de tempo. Quando a CI excede esse limite, muitas vezes durante uma rajada de instalações de pacotes ou pulls de imagem, o serviço responde com um erro de rate limit em vez de atender à requisição. É uma condição transitória que se resolve à medida que a janela reinicia.

## O que é rate limiting

Um rate limit é uma política que permite apenas um determinado número de requisições em um período (por minuto, por hora) de um dado cliente ou IP. Quando você cruza o limiar, o serviço recusa novas requisições até a janela reiniciar, tipicamente com o status 429 Too Many Requests, às vezes 403.

## Por que a CI o dispara

- Muitos jobs paralelos puxando as mesmas imagens ou pacotes de um único IP compartilhado.
- Requisições não autenticadas a registries, que costumam ter limites mais rígidos.
- Uma rajada de chamadas de API (atualizações de status, comentários) em um loop apertado.
- Retries sem backoff acumulando mais requisições durante uma janela limitada.

## Como ler a resposta

Respostas de rate limit muitas vezes incluem um header Retry-After ou headers de cota restante dizendo quando você pode tentar de novo. Respeitá-los é o comportamento correto: espere o tempo indicado em vez de fazer retry imediato e aprofundar o problema.

## Transitório, com uma ressalva

Um erro de rate limit é transitório porque a janela reinicia, então um retry após uma espera geralmente passa. Mas o retry certo é com backoff e ciente do Retry-After; fazer retry instantâneo apenas consome a próxima janela. Autenticar e usar cache reduzem a frequência com que você atinge limites de todo modo.

## A perspectiva da Latchkey

Os managed runners com autocorreção da Latchkey tratam erros de rate limit como 429s de registry como transitórios e fazem retry com backoff sensato, de modo que um rate limit isolado durante um build ocupado não faça seu build falhar, sem martelar o serviço limitado.

## Applying this to your pipeline

- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

## FAQ

### What is What is a rate limit Error? explained?

To protect themselves, services cap how many requests a client can make per unit of time. When CI exceeds that cap, often during a burst of package installs or image pulls, the service responds with a rate limit error instead of serving the request. It is a transient condition that clears as the window resets.

### What rate limiting is?

A rate limit is a policy that allows only so many requests in a period (per minute, per hour) from a given client or IP. When you cross the threshold, the service refuses further requests until the window resets, typically with status 429 Too Many Requests, sometimes 403.

### How to read the response?

Rate limit responses often include a Retry-After header or remaining-quota headers telling you when you may try again. Respecting those is the correct behavior: wait the indicated time rather than retrying immediately and deepening the problem.

### Transient, with a caveat?

A rate limit error is transient because the window resets, so a retry after a wait usually succeeds. But the right retry is backed off and Retry-After-aware; retrying instantly just consumes the next window. Authenticating and caching reduce how often you hit limits at all.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt