Skip to content

Código de status HTTP · Erros do servidor (5xx)

Erro 503 Service Unavailable

O erro 503 Service Unavailable (serviço indisponível) significa que o servidor não consegue atender o pedido agora, por sobrecarga ou manutenção, e espera se recuperar. As causas mais comuns são um pico de acessos que esgota os workers do servidor e um deploy ou janela de manutenção com a aplicação desligada.

Dados sobre este código de status
Classe5xx, Erros do servidor
Definido emRFC 9110 §15.6.4
Pode ir para o cache por padrãoSó com Cache-Control ou Expires explícitos; o cache só guarda com validade explícita; uma página de manutenção guardada pode durar mais que a manutenção
Pode repetir o pedidoSim, depois do tempo do Retry-After se vier, senão com espera exponencial
Cabeçalhos relevantes
  • Retry-After: segundos (Retry-After: 120) ou uma data HTTP dizendo ao cliente quando tentar de novo
  • Cache-Control: no-store impede a CDN de continuar servindo a página de manutenção depois que o site voltou

O que significa o 503

A RFC 9110, seção 15.6.4, descreve o 503 como o servidor incapaz de atender o pedido por sobrecarga temporária ou manutenção programada, algo que deve se resolver depois de algum tempo. A palavra que importa é temporário. O servidor pode incluir o cabeçalho Retry-After, em segundos ou como data HTTP, dizendo quando voltar.

Ao contrário do 502 e do 504, o 503 costuma ser uma decisão, não um acidente. Balanceadores devolvem 503 quando não há nenhum destino saudável registrado, o http.TimeoutHandler do Go devolve 503 quando o handler passa do prazo, e o módulo limit_req do nginx recusa o excesso de pedidos com 503, a menos que você defina limit_req_status 429.

Para buscadores, 503 com Retry-After é o jeito certo de tirar o site do ar para manutenção. O Google entende um 503 curto como "volte depois" e não como motivo para remover as páginas, coisa que uma página de manutenção com 200 ou um 404 não conseguem.

Causas comuns

Se você está visitando o site

  • O site está numa janela de manutenção programada ou no meio de um deploy.
  • Uma onda de visitantes, como venda de ingressos, lançamento ou link viral, esgotou a capacidade do site.
  • Seus pedidos acionaram o limitador de taxa do site, se ele estiver configurado para responder 503 em vez de 429.

Se você administra o servidor

  • Todos os workers estão ocupados: o PHP-FPM chegou ao pm.max_children, o pool do Gunicorn ou do Puma lotou, ou o pool de conexões do banco se esgotou, e os novos pedidos são recusados.
  • O balanceador não tem destinos saudáveis: todas as instâncias falham no health check, ou nenhuma foi registrada depois do deploy (um ALB da AWS responde 503 nesse caso).
  • Modo de manutenção ligado, por exemplo um arquivo de sinalização que o nginx verifica, ou uma opção de manutenção na própria hospedagem.
  • Um limitador de tempo cortou o pedido: o http.TimeoutHandler do Go escreve 503 quando o handler envolvido passa do prazo.
  • O limit_req ou limit_conn do nginx recusando rajadas com o status padrão 503.

Como resolver

Se você está visitando o site

  • Espere e tente de novo; se a página mostra um horário ou a resposta tem Retry-After, espere pelo menos esse tempo.
  • Veja a página de status do site ou as redes sociais dele atrás de um aviso de manutenção.
  • Não fique apertando F5 durante uma venda ou lançamento; cada nova tentativa soma à carga que causou o 503.

Se você administra o servidor

  • Descubra qual camada mandou o 503 (cabeçalho Server, logs do balanceador) antes de escalar qualquer coisa: um balanceador com zero destinos saudáveis precisa de um health check corrigido, não de mais instâncias.
  • Se os workers estão lotados, veja por que os pedidos estão lentos (consultas lentas, chamadas externas sem timeout) antes de aumentar pm.max_children ou o tamanho do pool, o que pode só mudar o gargalo para o banco.
  • Adicione capacidade ou autoscaling para picos reais, e coloque uma fila na frente do trabalho pesado para ele não prender os workers de requisição.
  • Na manutenção, responda 503 com Retry-After e Cache-Control: no-store, e seja breve; muitas horas de 503 começam a custar visibilidade nas buscas.
  • Se o 503 é na verdade limite de taxa, troque para 429, para o cliente diferenciar "você está rápido demais" de "estamos fora do ar".

Como enviar um 503

Express (Node.js)
app.post('/exports', (req, res) => {
  res.set('Retry-After', '120');
  res.status(503).json({ error: 'Export queue is full, try again in 2 minutes' });
});
Next.js App Router (route handler)
// app/exports/route.ts
export async function POST() {
  return Response.json(
    { error: 'Export queue is full, try again in 2 minutes' },
    { status: 503, headers: { 'Retry-After': '120' } }
  );
}
Go net/http
mux.HandleFunc("POST /exports", func(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Retry-After", "120")
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusServiceUnavailable) // 503
	w.Write([]byte(`{"error":"Export queue is full, try again in 2 minutes"}`))
})
Python FastAPI
from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.post("/exports")
def create_export():
    raise HTTPException(status_code=503, detail="Export queue is full, try again in 2 minutes", headers={"Retry-After": "120"})
Nginx
# Maintenance mode: touch /var/www/maintenance.on to enable
server {
  location / {
    if (-f /var/www/maintenance.on) {
      return 503;
    }
    proxy_pass http://app;
  }

  error_page 503 @maintenance;
  location @maintenance {
    add_header Retry-After 600 always;
    add_header Cache-Control no-store always;
    root /var/www/errors;
    rewrite ^ /maintenance.html break;
  }
}

Costuma ser confundido com

503 vs 429
O 429 diz que este cliente está mandando pedidos demais; o 503 diz que o servidor está com dificuldade para todo mundo. Limitadores de taxa devem usar 429, mesmo que o nginx use 503 por padrão.
503 vs 502
O 502 é um proxy relatando uma resposta quebrada do upstream; o 503 costuma ser uma recusa proposital de aceitar mais trabalho agora.
503 vs 500
O 500 é uma falha inesperada, sem promessa de recuperação; o 503 diz explicitamente que a situação é temporária.

Perguntas frequentes

Quanto tempo dura o erro 503 serviço indisponível?
Depende da causa. Deploy ou reinício passam em segundos ou minutos, manutenção programada dura a janela anunciada, e sobrecarga dura até o tráfego cair ou a capacidade aumentar. O cabeçalho Retry-After, quando existe, é a própria estimativa do servidor.
Usar 503 na manutenção é bom para o SEO?
Sim, é o status recomendado. O Googlebot entende um 503 temporário como motivo para tentar mais tarde, não para remover as páginas. Mantenha a parada curta: se a URL devolve 503 por dias, o Google começa a tratá-la como removida.
Limite de taxa deve devolver 503 ou 429?
Use 429 Too Many Requests, definido na RFC 6585 exatamente para isso, com Retry-After. O limit_req do nginx usa 503 por padrão por motivos históricos; configure limit_req_status 429 para mudar.
Por que meu balanceador de carga devolve 503?
Normalmente porque não tem nenhum backend saudável para onde mandar o pedido: todos falham no health check, o caminho do health check devolve erro, ou nenhum destino está registrado. Corrija o health check ou as instâncias, não o balanceador.
O que significa "503 Service Temporarily Unavailable"?
É o mesmo status 503 com outra frase de motivo. O Apache e alguns outros servidores usam "Service Temporarily Unavailable" nas páginas de erro padrão; o cliente só olha o número.

Revisado em por Arielton Oberek.