erro 503 serviço indisponível

Erro 503: o servidor está de pé e a dizer que não, agora não.

De todos os erros 5xx, o 503 é o único que às vezes é de propósito. Pode ser o site em manutenção, pode ser sobrecarga, pode ser um plugin que se enganou — e distingui-los é a primeira coisa a fazer.

O 503 é a única resposta 5xx que uma equipa devolve de propósito. É o código correcto para "estou em manutenção" e para "estou sobrecarregado, volta daqui a pouco" — e por isso o mesmo número tanto pode ser um plano a correr bem como um servidor a afogar-se.

A diferença entre os dois vê-se na resposta. Uma manutenção declarada devolve normalmente uma página com texto e, se estiver bem feita, um cabeçalho `Retry-After` a dizer quando voltar. Uma sobrecarga devolve a página de erro genérica do servidor, sem explicação nenhuma.

No WordPress há um terceiro caso que engana toda a gente: durante uma actualização, o WordPress cria um ficheiro `.maintenance` e devolve 503 a todos os visitantes. Se a actualização falhar a meio, o ficheiro fica lá — e o site fica em manutenção para sempre sem ninguém ter pedido nada.

// a ficha

O que este código diz, em cinco linhas.

Código
503 Service Unavailable
Família
5xx — erro do servidor
Significado literal
temporariamente indisponível
Pode ser intencional
sim — é o único 5xx que costuma ser
Cabeçalho a procurar
Retry-After, quando existe

// causas prováveis

Por onde é que isto costuma vir.

Por ordem de frequência e não por ordem de gravidade. A primeira da lista explica mais casos do que as outras todas juntas.

  • Uma actualização do WordPress que ficou a meio

    O ficheiro `.maintenance` na raiz é criado no início da actualização e apagado no fim. Se o processo morreu pelo meio, ninguém o apaga. Apagá-lo à mão devolve o site imediatamente — e é o primeiro sítio onde olhar.

  • Sobrecarga — mais pedidos do que capacidade

    Uma campanha, um bot agressivo, um plugin a fazer trabalho pesado a cada visita. O servidor prefere recusar depressa a aceitar tudo e ficar lento para todos. Vê-se por vir e ir conforme o tráfego.

  • Manutenção declarada pelo alojamento

    Migrações, actualizações de infraestrutura, intervenções agendadas. Costuma haver aviso por email dias antes — e costuma estar numa caixa que ninguém abre.

  • Limites de recursos do plano atingidos

    Alojamentos partilhados cortam quando o site passa dos processos ou da CPU contratados. O site fica em 503 durante uns minutos, volta, e repete no dia seguinte à mesma hora.

  • Um firewall ou plugin de segurança a bloquear

    Alguns devolvem 503 em vez de 403 quando decidem que o pedido é suspeito. Se o 503 aparece só para ti e para mais ninguém, é a hipótese mais provável.

// diagnóstico

Passo a passo, do que custa menos ao que custa mais.

Cada passo elimina hipóteses. Saltar um passo poupa dois minutos e costuma custar uma hora — a ordem é a parte que interessa.

  1. 01

    Lê a página de erro antes de mexer em nada

    Uma manutenção declarada tem texto escrito por alguém. Uma sobrecarga tem a página genérica do servidor. São dois problemas diferentes com o mesmo número, e a página diz-te qual deles é em dois segundos.

  2. 02

    Confirma se é para todos

    Verifica de fora, a partir de outra rede. Se a verificação externa devolver 200 e tu continuares a ver 503, foste tu que foste bloqueado — provavelmente por um firewall do alojamento, e resolve-se a pedir o desbloqueio do teu IP.

  3. 03

    Se é WordPress, procura o ficheiro .maintenance

    Está na raiz da instalação, ao lado do `wp-config.php`, e é invisível se o gestor de ficheiros não mostrar ficheiros ocultos. Apaga-o. Se o site voltar, a actualização que falhou tem de ser refeita — mas já com o site de pé.

  4. 04

    Vê se o padrão é horário

    Um 503 que aparece sempre à mesma hora é um cron, um backup ou um pico de tráfego previsível. Um 503 aleatório é sobrecarga a sério. A diferença está no registo, e sem registo é impossível dizer qual dos dois é.

  5. 05

    Pergunta ao alojamento se cortaram recursos

    É a pergunta directa, e a resposta costuma ser sim ou não sem rodeios. Muitos painéis mostram o consumo de CPU e de processos por hora — se houver um pico a bater no tecto à mesma hora do erro, está encontrado.

O primeiro passo é sempre o mesmo — ver de fora o que o servidor responde de facto. Faz isso aqui, a partir de um servidor em Portugal. Sem conta, sem custo, e não guardamos o que verificares.

verificar_site servidor: PT

// que não volte

Como evitar que volte a acontecer sem dares por isso.

Resolver o incidente é metade do trabalho. A outra metade é a parte que ninguém factura e é a que decide se há um terceiro.

  • Actualiza o WordPress com o site a ser vigiado

    A actualização que falha a meio deixa o site em 503 e não avisa ninguém. Se a verificação estiver a correr, ficas a saber em minutos em vez de descobrires no dia seguinte.

  • Põe cache à frente do PHP

    A maior parte das sobrecargas são páginas públicas a serem geradas de novo para cada visitante. Uma cache de página bem configurada corta o problema pela raiz e é a mudança com melhor relação entre esforço e efeito.

  • Trava os bots que não trazem nada

    Uma fatia grande do tráfego de um site pequeno são raspadores. Bloqueá-los devolve capacidade sem custar um cêntimo de alojamento.

  • Marca as manutenções em vez de as improvisar

    Uma intervenção anunciada não é um incidente. Uma intervenção improvisada é indistinguível de uma avaria — para o cliente, e para qualquer relatório que venhas a escrever.

// limites

Onde é que esta página encalha.

Uma página de diagnóstico que não diz onde acaba manda-te dar voltas até desistires. Estes são os casos em que não chega.

  • Esta página não distingue sobrecarga de ataque. Um pico de pedidos malicioso e uma campanha bem sucedida parecem iguais do lado de fora; separá-los exige ver os logs de acesso.
  • Se o 503 vem de uma manutenção do alojamento, não há nada a fazer do teu lado a não ser avisar o cliente. Isso é comunicação e não diagnóstico.
  • Não dizemos quantos processos ou quanta CPU o teu site devia ter. Depende do que ele faz, e quem tem esses números é o teu alojamento.
  • Um 503 que dura dias já não é temporário e o código está errado. Nessa altura, a pergunta a fazer ao alojamento é outra.

// perguntas

O que nos perguntam a seguir.

O erro 503 prejudica o SEO?

Um 503 curto não prejudica, e é para isso que ele serve: diz ao Google que o problema é temporário e que ele deve voltar mais tarde. É por isso que uma manutenção deve devolver 503 e nunca 404 nem 500. Se durar dias, aí sim, o Google começa a tratar as páginas como indisponíveis.

Como é que ponho o meu site em manutenção da forma correcta?

A devolver 503 com um cabeçalho `Retry-After` e uma página que explique o que se passa. Qualquer plugin de manutenção decente faz isto — o que muitos fazem mal é devolver 200 numa página que diz "voltamos já", o que para um motor de busca é uma página normal com pouco conteúdo.

O site volta sozinho depois de um 503?

Se a causa foi sobrecarga, quase sempre volta assim que o pico passar. Se foi o ficheiro `.maintenance` do WordPress, não volta — fica assim indefinidamente até alguém apagar o ficheiro. É por isso que este é o primeiro sítio onde se olha.

E se acontecer às três da manhã?

Metade dos 503 resolvem-se sozinhos e a outra metade fica até alguém reparar. O problema é que os dois casos são iguais no primeiro minuto, e a diferença entre um incidente de cinco minutos e um de cinco horas é só quem estava a olhar. A De Olho vai olhar ao minuto e avisar-te no canal onde já estás — e o histórico fica lá para quando alguém perguntar se isto já tinha acontecido antes.

A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.