{"id":18002,"date":"2021-05-13T11:43:39","date_gmt":"2021-05-13T11:43:39","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/05\/13\/os-10-codigos-de-status-http-mais-comuns\/"},"modified":"2026-05-31T20:27:25","modified_gmt":"2026-05-31T20:27:25","slug":"os-10-codigos-de-status-http-mais-comuns","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/os-10-codigos-de-status-http-mais-comuns\/","title":{"rendered":"Os C\u00f3digos de Status HTTP Mais Comuns (E O Que Fazer Sobre Cada Um)"},"content":{"rendered":"<figure id=\"attachment_33970\" aria-describedby=\"caption-attachment-33970\" style=\"width: 1536px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-33970\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes.webp\" alt=\"Refer\u00eancia visual dos c\u00f3digos de status HTTP mais comuns agrupados por categoria\u20142xx sucesso, 3xx redirecionamento, 4xx erro do cliente, 5xx erro do servidor\" width=\"1536\" height=\"1024\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-768x512.webp 768w\" sizes=\"(max-width: 1536px) 100vw, 1536px\" \/><figcaption id=\"caption-attachment-33970\" class=\"wp-caption-text\">As cinco categorias de c\u00f3digos de status HTTP e os c\u00f3digos que voc\u00ea realmente ver\u00e1 em produ\u00e7\u00e3o.<\/figcaption><\/figure>\n<p>Seu pager dispara \u00e0s 2 da manh\u00e3. A carga do alerta tem um c\u00f3digo de status. O que voc\u00ea faz a seguir depende quase inteiramente de qual c\u00f3digo voc\u00ea v\u00ea.<\/p>\n<p>Essa \u00e9 a parte que a maioria dos guias de c\u00f3digos de status HTTP pula. Eles listam defini\u00e7\u00f5es, classificam os c\u00f3digos em cinco grupos e param. \u00datil como gloss\u00e1rio, menos \u00fatil quando um endpoint real est\u00e1 lan\u00e7ando 502s e um executivo pergunta por que o checkout est\u00e1 quebrado.<\/p>\n<p>Este guia cobre os mesmos dez c\u00f3digos que voc\u00ea ver\u00e1 com mais frequ\u00eancia, al\u00e9m de algumas men\u00e7\u00f5es honrosas. Para cada um: o que significa, o que normalmente o dispara em produ\u00e7\u00e3o, e o que verificar primeiro. O objetivo \u00e9 encurtar o tempo entre &#8220;vejo o c\u00f3digo&#8221; e &#8220;sei o que consertar.&#8221;<\/p>\n<h2 id='o-que-\u00e9-um-c\u00f3digo-de-status-http'  id=\"boomdevs_1\">O Que \u00c9 um C\u00f3digo de Status HTTP?<\/h2>\n<p>Um c\u00f3digo de status HTTP \u00e9 um n\u00famero de tr\u00eas d\u00edgitos que o servidor envia de volta com cada resposta. Ele informa ao cliente se a solicita\u00e7\u00e3o teve sucesso, falhou ou precisa ser redirecionada. Voc\u00ea os v\u00ea em todo lugar: na guia Network das DevTools do seu navegador, em logs de balanceadores de carga, em alertas de monitoramento, em pain\u00e9is de CDN. Este guia foca naqueles que realmente acordam as pessoas.<\/p>\n<h2 id='as-cinco-categorias-de-c\u00f3digos-de-status-http'  id=\"boomdevs_2\">As Cinco Categorias de C\u00f3digos de Status HTTP<\/h2>\n<p>O primeiro d\u00edgito do c\u00f3digo indica a classe da resposta:<\/p>\n<ul>\n<li><strong>1xx Informativo.<\/strong> Raro no trabalho di\u00e1rio. Usado principalmente para negocia\u00e7\u00e3o de protocolo (100 Continue, 101 Switching Protocols para atualiza\u00e7\u00f5es WebSocket).<\/li>\n<li><strong>2xx Sucesso.<\/strong> A solicita\u00e7\u00e3o funcionou. 200 \u00e9 o padr\u00e3o; 201 significa que um recurso foi criado; 204 significa sucesso sem corpo.<\/li>\n<li><strong>3xx Redirecionamento.<\/strong> O recurso est\u00e1 em outro lugar. Navegadores e crawlers seguem esses automaticamente at\u00e9 um limite.<\/li>\n<li><strong>4xx Erro do Cliente.<\/strong> A solicita\u00e7\u00e3o estava errada. URL errada, autentica\u00e7\u00e3o ausente, permiss\u00f5es bloqueadas, payload malformado.<\/li>\n<li><strong>5xx Erro do Servidor.<\/strong> A solicita\u00e7\u00e3o estava correta. O servidor falhou ao atend\u00ea-la.<\/li>\n<\/ul>\n<p>A divis\u00e3o entre 4xx e 5xx \u00e9 a parte que mais importa para o triagem. Um 4xx diz &#8220;quem chamou fez algo errado.&#8221; Um 5xx diz &#8220;n\u00f3s fizemos algo errado.&#8221; O primeiro volta para quem chamou o endpoint. O segundo vai para voc\u00ea.<\/p>\n<p>Para uma enumera\u00e7\u00e3o completa, a <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/http-status-codes-list\/\">refer\u00eancia completa de c\u00f3digos de status HTTP<\/a> na wiki da Dotcom-Monitor lista todos os c\u00f3digos definidos na especifica\u00e7\u00e3o. O resto deste guia foca nos que realmente aparecem em alertas.<\/p>\n<h2 id='os-dez-c\u00f3digos-de-status-http-mais-comuns'  id=\"boomdevs_3\">Os Dez C\u00f3digos de Status HTTP Mais Comuns<\/h2>\n<h3 id='200-ok'  id=\"boomdevs_4\">200 OK<\/h3>\n<p>O servidor processou a solicita\u00e7\u00e3o e retornou a resposta esperada. Este \u00e9 o c\u00f3digo que voc\u00ea quer ver na imensa maioria das requisi\u00e7\u00f5es para um site de produ\u00e7\u00e3o saud\u00e1vel.<\/p>\n<p><strong>Cuidado com:<\/strong> um 200 OK n\u00e3o \u00e9 prova de que a p\u00e1gina est\u00e1 correta. JavaScript pode falhar silenciosamente e renderizar uma p\u00e1gina em branco. Uma API pode retornar 200 com um corpo de erro. Um formul\u00e1rio de login pode mostrar &#8220;credenciais inv\u00e1lidas&#8221; dentro de uma resposta 200. Checagens apenas por c\u00f3digo de status n\u00e3o detectam isso. Combine com checagens em navegador real (mais sobre isso abaixo).<\/p>\n<h3 id='301-moved-permanently'  id=\"boomdevs_5\">301 Moved Permanently<\/h3>\n<p>O recurso tem uma nova URL permanente. Navegadores cacheiam o redirecionamento agressivamente. Motores de busca transferem a maior parte da autoridade do link para o destino.<\/p>\n<p><strong>Use para:<\/strong> mudan\u00e7as de URL ap\u00f3s migra\u00e7\u00e3o de site, trocar HTTP por HTTPS, consolidar caminhos duplicados, desativar slugs antigos. Uma vez que um 301 est\u00e1 ativo e em cache, revert\u00ea-lo \u00e9 doloroso\u2014navegadores e crawlers continuar\u00e3o indo para o novo local por semanas.<\/p>\n<h3 id='302-found-redirecionamento-tempor\u00e1rio'  id=\"boomdevs_6\">302 Found (Redirecionamento Tempor\u00e1rio)<\/h3>\n<p>O recurso est\u00e1 temporariamente em outro lugar. Navegadores n\u00e3o cacheiam o redirecionamento, e motores de busca n\u00e3o transferem toda a autoridade do link.<\/p>\n<p><strong>Cuidado com:<\/strong> 302 \u00e9 usado demais. Times o escolhem porque o helper de redirecionamento padr\u00e3o do framework retorna 302. Se a mudan\u00e7a \u00e9 permanente, use 301. Se precisar preservar o m\u00e9todo HTTP (POST continua POST), use 307 ou 308. O Google eventualmente tratar\u00e1 302 persistentes como 301, mas &#8220;eventualmente&#8221; n\u00e3o \u00e9 uma estrat\u00e9gia.<\/p>\n<h3 id='400-bad-request'  id=\"boomdevs_7\">400 Bad Request<\/h3>\n<p>O servidor n\u00e3o consegue interpretar a solicita\u00e7\u00e3o. JSON malformado, cabe\u00e7alhos inv\u00e1lidos, payloads muito grandes, viola\u00e7\u00f5es de esquema.<\/p>\n<p><strong>Verifique primeiro:<\/strong> o corpo da solicita\u00e7\u00e3o. Um pico de 400s em um endpoint de API geralmente significa que um cliente come\u00e7ou a enviar uma estrutura errada\u2014um deploy do lado do consumidor, uma mudan\u00e7a de esquema do seu lado, ou uma integra\u00e7\u00e3o de terceiros que atualizou o formato. Compare o payload da solicita\u00e7\u00e3o com a \u00faltima vers\u00e3o boa conhecida.<\/p>\n<h3 id='401-unauthorized'  id=\"boomdevs_8\">401 Unauthorized<\/h3>\n<p>A solicita\u00e7\u00e3o n\u00e3o tem credenciais, ou as credenciais foram rejeitadas. O nome \u00e9 enganoso\u2014a quest\u00e3o \u00e9 autentica\u00e7\u00e3o, n\u00e3o autoriza\u00e7\u00e3o.<\/p>\n<p><strong>Verifique primeiro:<\/strong> tokens. Um pico s\u00fabito de 401 em endpoints que antes funcionavam pode significar token expirado, chave de assinatura rotacionada, problema no provedor OIDC, ou algu\u00e9m mudou a claim de audi\u00eancia. Se seu <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/api-availability-monitoring\/\">monitoramento de disponibilidade de API<\/a> mostra 401s onde havia 200s, a camada de autentica\u00e7\u00e3o geralmente \u00e9 o culpado.<\/p>\n<h3 id='403-forbidden'  id=\"boomdevs_9\">403 Forbidden<\/h3>\n<p>As credenciais s\u00e3o v\u00e1lidas, mas o chamador n\u00e3o tem permiss\u00e3o para acessar este recurso. O problema \u00e9 autoriza\u00e7\u00e3o, n\u00e3o autentica\u00e7\u00e3o.<\/p>\n<p><strong>Verifique primeiro:<\/strong> permiss\u00f5es e regras da infraestrutura. 403s aparecem quando uma pol\u00edtica IAM muda, uma regra WAF come\u00e7a a bloquear tr\u00e1fego leg\u00edtimo, uma pol\u00edtica de acesso CDN fica muito agressiva, ou uma flag de recurso \u00e9 ativada para o segmento errado de usu\u00e1rios. Se 403s come\u00e7aram logo ap\u00f3s um deploy, examine as diferen\u00e7as de pol\u00edticas e configura\u00e7\u00f5es antes do c\u00f3digo da aplica\u00e7\u00e3o.<\/p>\n<h3 id='404-not-found'  id=\"boomdevs_10\">404 Not Found<\/h3>\n<p>O servidor entendeu a solicita\u00e7\u00e3o mas n\u00e3o tem recurso na URL. O c\u00f3digo de status mais famoso da exist\u00eancia.<\/p>\n<p><strong>Dois cen\u00e1rios para separar:<\/strong><\/p>\n<ul>\n<li><strong>404s isolados<\/strong> por erros de digita\u00e7\u00e3o, favoritos antigos ou crawlers procurando vulnerabilidades. Esses s\u00e3o ru\u00eddo de fundo.<\/li>\n<li><strong>Um surto de 404s em URLs can\u00f4nicos<\/strong> logo ap\u00f3s um deploy. Isso \u00e9 um release quebrado\u2014rotas removidas, artefato da build faltando, ou algu\u00e9m lan\u00e7ou uma mudan\u00e7a de slug sem redirecionamentos. Fa\u00e7a rollback ou lance um hotfix.<\/li>\n<\/ul>\n<p>404s persistentes em p\u00e1ginas indexadas acabar\u00e3o sendo desindexados pelo Google, ent\u00e3o p\u00e1ginas can\u00f4nicas que retornam 404 tamb\u00e9m t\u00eam um custo SEO.<\/p>\n<h4 id='como-corrigir'  id=\"boomdevs_11\">Como Corrigir<\/h4>\n<p><strong>Caminho r\u00e1pido:<\/strong> se a p\u00e1gina mudou, adicione um redirecionamento 301 da URL antiga para a nova para que usu\u00e1rios e crawlers caiam no lugar certo. Se a p\u00e1gina realmente sumiu, retorne um 404 ou 410 real em vez de um redirecionamento vago para a homepage.<\/p>\n<p><strong>Corre\u00e7\u00e3o real:<\/strong> audite a origem dos 404s. Links internos quebrados s\u00e3o corrigidos na fonte; rotas faltando ap\u00f3s deploy recebem hotfix; uma migra\u00e7\u00e3o ruim que removeu slugs precisa de um mapa de redirecionamento. Fa\u00e7a crawling peri\u00f3dico do seu site para encontrar links mortos antes do Google.<\/p>\n<h3 id='500-internal-server-error'  id=\"boomdevs_12\">500 Internal Server Error<\/h3>\n<p>O servidor encontrou uma exce\u00e7\u00e3o n\u00e3o tratada. O 5xx gen\u00e9rico. Diz que algo quebrou, mas n\u00e3o o que.<\/p>\n<p><strong>Verifique primeiro:<\/strong> logs da aplica\u00e7\u00e3o. Todo 500 tem um stack trace em algum lugar\u2014se n\u00e3o tiver, seu sistema de logs precisa de ajustes antes do c\u00f3digo. Gatilhos comuns: exce\u00e7\u00e3o n\u00e3o capturada em c\u00f3digo rec\u00e9m-deployado, depend\u00eancia downstream retornando formato inesperado, pool de conex\u00e3o com banco esgotado, loop de rein\u00edcio por falta de mem\u00f3ria. Um pico sustentado de 500 em produ\u00e7\u00e3o deve disparar pagina\u00e7\u00e3o on-call.<\/p>\n<h4 id='como-corrigir-1'  id=\"boomdevs_13\">Como Corrigir<\/h4>\n<p><strong>Caminho r\u00e1pido:<\/strong> se o pico come\u00e7ou logo ap\u00f3s um release, fa\u00e7a rollback. Um 500 que aparece minutos ap\u00f3s o deploy \u00e9 o deploy at\u00e9 prova em contr\u00e1rio.<\/p>\n<p><strong>Corre\u00e7\u00e3o real:<\/strong> leia o stack trace e corrija o caminho de c\u00f3digo com erro, depois adicione teste de regress\u00e3o para n\u00e3o voltar. Se o gatilho foi um limite de recurso\u2014pool de conex\u00f5es, mem\u00f3ria, handle de arquivo\u2014eleve o limite e configure alerta antes de atingir novamente.<\/p>\n<h3 id='502-bad-gateway'  id=\"boomdevs_14\">502 Bad Gateway<\/h3>\n<p>Um proxy, balanceador de carga ou CDN recebeu resposta inv\u00e1lida do servidor upstream. O proxy est\u00e1 saud\u00e1vel. O que est\u00e1 atr\u00e1s dele n\u00e3o est\u00e1.<\/p>\n<p><strong>Verifique primeiro:<\/strong> sa\u00fade do upstream. Gatilhos comuns: container da aplica\u00e7\u00e3o caiu e o load balancer ainda est\u00e1 roteando para ele, upstream est\u00e1 expirando antes de responder, pod Kubernetes em CrashLoopBackOff, worker Nginx mal configurado, ou conex\u00e3o entre proxy e upstream resetada. 502 \u00e9 um dos c\u00f3digos mais informativos em arquiteturas em camadas\u2014diz que a borda est\u00e1 ok e o problema est\u00e1 um salto atr\u00e1s.<\/p>\n<h4 id='como-corrigir-2'  id=\"boomdevs_15\">Como Corrigir<\/h4>\n<p><strong>Caminho r\u00e1pido:<\/strong> reinicie ou substitua a inst\u00e2ncia upstream com problema e confirme que os health checks do load balancer removem os n\u00f3s mortos da rota\u00e7\u00e3o.<\/p>\n<p><strong>Corre\u00e7\u00e3o real:<\/strong> descubra por que o upstream retornou lixo. Verifique se o timeout do proxy \u00e9 menor que o tempo real de resposta do upstream, se o pod est\u00e1 em loop de crash na inicializa\u00e7\u00e3o, e se as configura\u00e7\u00f5es de keep-alive coincidem dos dois lados da conex\u00e3o.<\/p>\n<h3 id='503-service-unavailable'  id=\"boomdevs_16\">503 Service Unavailable<\/h3>\n<p>O servidor est\u00e1 temporariamente incapaz de atender o pedido. Capacidade esgotada, modo de manuten\u00e7\u00e3o, autoscaler ainda iniciando.<\/p>\n<p><strong>Verifique primeiro:<\/strong> satura\u00e7\u00e3o de recursos e limites de taxa. 503s em pico de tr\u00e1fego geralmente significam que autoscaler n\u00e3o acompanha ou limite de conex\u00e3o foi alcan\u00e7ado. 503s em estado est\u00e1vel geralmente indicam processo em manuten\u00e7\u00e3o ou fila congestionada. Algumas plataformas tamb\u00e9m retornam 503 quando WAF ou sistema anti-bot upstream limita a taxa de um solicitante\u2014vale a pena verificar antes de assumir que a aplica\u00e7\u00e3o \u00e9 o problema.<\/p>\n<h4 id='como-corrigir-3'  id=\"boomdevs_17\">Como Corrigir<\/h4>\n<p><strong>Caminho r\u00e1pido:<\/strong> retorne o 503 com um cabe\u00e7alho <code>Retry-After<\/code> para que clientes e crawlers bem comportados recuem em vez de bombardear o servidor em dificuldades. Em PHP:<\/p>\n<pre><code>http_response_code(503);\nheader('Retry-After: 60');<\/code><\/pre>\n<p><strong>Corre\u00e7\u00e3o real:<\/strong> encontre o recurso saturado\u2014conex\u00f5es ao banco, pool de workers, limite do autoscaler\u2014e remova o gargalo. Se o 503 veio de limite de taxa do CDN ou WAF, aumente o limite ou coloque o solicitante leg\u00edtimo em lista branca.<\/p>\n<h2 id='outros-c\u00f3digos-que-vale-conhecer'  id=\"boomdevs_18\">Outros C\u00f3digos Que Vale Conhecer<\/h2>\n<p>Os dez acima cobrem a maior parte do tr\u00e1fego de produ\u00e7\u00e3o. Mas alguns outros aparecem com frequ\u00eancia suficiente em incidentes reais para que engenheiros on-call os conhe\u00e7am de vista.<\/p>\n<ul>\n<li><strong>304 Not Modified.<\/strong> Enviado quando um recurso em cache ainda est\u00e1 fresco. Comum em tr\u00e1fego com CDN na frente. Queda nos 304 pode significar mudan\u00e7a nos cabe\u00e7alhos cache-control e aumento de uso de banda de origem.<\/li>\n<li><strong>307 Temporary Redirect.<\/strong> Como 302, mas preserva o m\u00e9todo HTTP. Um POST continua POST. Use 307 em vez de 302 para redirecionar formul\u00e1rios ou chamadas API n\u00e3o idempotentes.<\/li>\n<li><strong>308 Permanent Redirect.<\/strong> Como 301, mas preserva o m\u00e9todo HTTP. A escolha moderna para redirecionamentos permanentes de endpoints API que usam POST, PUT, PATCH ou DELETE.<\/li>\n<li><strong>429 Too Many Requests.<\/strong> Limite de taxa atingido. Ou voc\u00ea est\u00e1 sendo limitado por uma API upstream ou est\u00e1 limitando algu\u00e9m. Verifique cabe\u00e7alhos <code>Retry-After<\/code>; respeite-os.<\/li>\n<li><strong>504 Gateway Timeout.<\/strong> Proxy desistiu de esperar pelo upstream. Diferente de 502 pois o upstream n\u00e3o retornou uma resposta ruim\u2014n\u00e3o retornou resposta a tempo. Normalmente uma query longa, worker congelado, ou API downstream lenta.<\/li>\n<\/ul>\n<h3 id='301-vs-302-vs-307-vs-308'  id=\"boomdevs_19\">301 vs 302 vs 307 vs 308<\/h3>\n<p>Os quatro c\u00f3digos de redirecionamento s\u00e3o confundidos constantemente. A diferen\u00e7a se baseia em duas coisas: se a mudan\u00e7a \u00e9 permanente e se o m\u00e9todo HTTP \u00e9 preservado.<\/p>\n<div class=\"table-wrap\">\n<table class=\"compare\">\n<thead>\n<tr>\n<th>Comportamento<\/th>\n<th>301<\/th>\n<th>302<\/th>\n<th>307<\/th>\n<th>308<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Perman\u00eancia<\/td>\n<td>Permanent<\/td>\n<td>Tempor\u00e1rio<\/td>\n<td>Tempor\u00e1rio<\/td>\n<td>Permanent<\/td>\n<\/tr>\n<tr>\n<td>M\u00e9todo preservado<\/td>\n<td>N\u00e3o garantido<\/td>\n<td>N\u00e3o garantido<\/td>\n<td>Sim<\/td>\n<td>Sim<\/td>\n<\/tr>\n<tr>\n<td>Cacheado por navegadores<\/td>\n<td>Agressivamente<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<\/tr>\n<tr>\n<td>Equidade de link passada<\/td>\n<td>Maioria<\/td>\n<td>Limitada<\/td>\n<td>Limitada<\/td>\n<td>Maioria<\/td>\n<\/tr>\n<tr>\n<td>Use quando<\/td>\n<td>Mudan\u00e7a permanente de URL<\/td>\n<td>Mudan\u00e7a tempor\u00e1ria<\/td>\n<td>Redirecionamento de formul\u00e1rio ou POST<\/td>\n<td>Endpoint API movido permanentemente<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Para uma p\u00e1gina comum que mudou para sempre, use 301. Quando o redirecionamento precisa manter um POST como POST\u2014envio de formul\u00e1rio ou chamada API n\u00e3o idempotente\u2014use 307 se a mudan\u00e7a for tempor\u00e1ria ou 308 se for permanente.<\/p>\n<h2 id='a-refer\u00eancia-completa-de-c\u00f3digos-de-status-http'  id=\"boomdevs_20\">A Refer\u00eancia Completa de C\u00f3digos de Status HTTP<\/h2>\n<p>Os c\u00f3digos acima cobrem quase tudo que dispara alerta real. Para os incomuns\u2014que aparecem uma vez por trimestre e fazem voc\u00ea parar para buscar\u2014aqui est\u00e1 a lista padr\u00e3o completa, al\u00e9m dos c\u00f3digos n\u00e3o padr\u00e3o que voc\u00ea ver\u00e1 de fornecedores comuns de infraestrutura.<\/p>\n<h3 id='1xx-informativo'  id=\"boomdevs_21\">1xx Informativo<\/h3>\n<p>O servidor recebeu a solicita\u00e7\u00e3o e continua processando. Voc\u00ea raramente ver\u00e1 isso em logs de aplica\u00e7\u00e3o porque a maioria dos clientes e proxies os lida de forma transparente.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>100<\/td>\n<td>Continue<\/td>\n<\/tr>\n<tr>\n<td>101<\/td>\n<td>Switching Protocols<\/td>\n<\/tr>\n<tr>\n<td>102<\/td>\n<td>Processing<\/td>\n<\/tr>\n<tr>\n<td>103<\/td>\n<td>Early Hints<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='2xx-sucesso'  id=\"boomdevs_22\">2xx Sucesso<\/h3>\n<p>A solicita\u00e7\u00e3o foi recebida, compreendida e aceita. 200 \u00e9 a principal; os demais importam quando se constr\u00f3i APIs ou se trabalha com conte\u00fado parcial, WebDAV, ou opera\u00e7\u00f5es em lote.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>200<\/td>\n<td>OK<\/td>\n<\/tr>\n<tr>\n<td>201<\/td>\n<td>Created<\/td>\n<\/tr>\n<tr>\n<td>202<\/td>\n<td>Accepted<\/td>\n<\/tr>\n<tr>\n<td>203<\/td>\n<td>Non-Authoritative Information<\/td>\n<\/tr>\n<tr>\n<td>204<\/td>\n<td>No Content<\/td>\n<\/tr>\n<tr>\n<td>205<\/td>\n<td>Reset Content<\/td>\n<\/tr>\n<tr>\n<td>206<\/td>\n<td>Partial Content<\/td>\n<\/tr>\n<tr>\n<td>207<\/td>\n<td>Multi-Status<\/td>\n<\/tr>\n<tr>\n<td>208<\/td>\n<td>Already Reported<\/td>\n<\/tr>\n<tr>\n<td>226<\/td>\n<td>IM Used<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='3xx-redirecionamento'  id=\"boomdevs_23\">3xx Redirecionamento<\/h3>\n<p>O recurso est\u00e1 em outro lugar, ou a c\u00f3pia em cache ainda \u00e9 boa. 301 e 302 dominam; os outros importam para APIs (307\/308 preservam o m\u00e9todo HTTP) e pipelines de cache (304 economiza banda de origem).<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>300<\/td>\n<td>Multiple Choices<\/td>\n<\/tr>\n<tr>\n<td>301<\/td>\n<td>Moved Permanently<\/td>\n<\/tr>\n<tr>\n<td>302<\/td>\n<td>Found<\/td>\n<\/tr>\n<tr>\n<td>303<\/td>\n<td>See Other<\/td>\n<\/tr>\n<tr>\n<td>304<\/td>\n<td>Not Modified<\/td>\n<\/tr>\n<tr>\n<td>305<\/td>\n<td>Use Proxy (deprecated)<\/td>\n<\/tr>\n<tr>\n<td>306<\/td>\n<td>Switch Proxy (unused)<\/td>\n<\/tr>\n<tr>\n<td>307<\/td>\n<td>Temporary Redirect<\/td>\n<\/tr>\n<tr>\n<td>308<\/td>\n<td>Permanent Redirect<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='4xx-erros-do-cliente'  id=\"boomdevs_24\">4xx Erros do Cliente<\/h3>\n<p>A solicita\u00e7\u00e3o estava errada. A maioria voc\u00ea nunca ver\u00e1; meia d\u00fazia comuns aparecem diariamente. Vale saber que existem raros para n\u00e3o perder tempo tentando adivinhar quando um 418 ou 451 aparece no log.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>400<\/td>\n<td>Bad Request<\/td>\n<\/tr>\n<tr>\n<td>401<\/td>\n<td>Unauthorized<\/td>\n<\/tr>\n<tr>\n<td>402<\/td>\n<td>Payment Required<\/td>\n<\/tr>\n<tr>\n<td>403<\/td>\n<td>Forbidden<\/td>\n<\/tr>\n<tr>\n<td>404<\/td>\n<td>Not Found<\/td>\n<\/tr>\n<tr>\n<td>405<\/td>\n<td>Method Not Allowed<\/td>\n<\/tr>\n<tr>\n<td>406<\/td>\n<td>Not Acceptable<\/td>\n<\/tr>\n<tr>\n<td>407<\/td>\n<td>Proxy Authentication Required<\/td>\n<\/tr>\n<tr>\n<td>408<\/td>\n<td>Request Timeout<\/td>\n<\/tr>\n<tr>\n<td>409<\/td>\n<td>Conflict<\/td>\n<\/tr>\n<tr>\n<td>410<\/td>\n<td>Gone<\/td>\n<\/tr>\n<tr>\n<td>411<\/td>\n<td>Length Required<\/td>\n<\/tr>\n<tr>\n<td>412<\/td>\n<td>Precondition Failed<\/td>\n<\/tr>\n<tr>\n<td>413<\/td>\n<td>Payload Too Large<\/td>\n<\/tr>\n<tr>\n<td>414<\/td>\n<td>URI Too Long<\/td>\n<\/tr>\n<tr>\n<td>415<\/td>\n<td>Unsupported Media Type<\/td>\n<\/tr>\n<tr>\n<td>416<\/td>\n<td>Range Not Satisfiable<\/td>\n<\/tr>\n<tr>\n<td>417<\/td>\n<td>Expectation Failed<\/td>\n<\/tr>\n<tr>\n<td>418<\/td>\n<td>I&#8217;m a teapot<\/td>\n<\/tr>\n<tr>\n<td>421<\/td>\n<td>Misdirected Request<\/td>\n<\/tr>\n<tr>\n<td>422<\/td>\n<td>Unprocessable Content<\/td>\n<\/tr>\n<tr>\n<td>423<\/td>\n<td>Locked<\/td>\n<\/tr>\n<tr>\n<td>424<\/td>\n<td>Failed Dependency<\/td>\n<\/tr>\n<tr>\n<td>425<\/td>\n<td>Too Early<\/td>\n<\/tr>\n<tr>\n<td>426<\/td>\n<td>Upgrade Required<\/td>\n<\/tr>\n<tr>\n<td>428<\/td>\n<td>Precondition Required<\/td>\n<\/tr>\n<tr>\n<td>429<\/td>\n<td>Too Many Requests<\/td>\n<\/tr>\n<tr>\n<td>431<\/td>\n<td>Request Header Fields Too Large<\/td>\n<\/tr>\n<tr>\n<td>451<\/td>\n<td>Unavailable For Legal Reasons<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='5xx-erros-do-servidor'  id=\"boomdevs_25\">5xx Erros do Servidor<\/h3>\n<p>A solicita\u00e7\u00e3o estava correta. Algo no lado do servidor falhou. S\u00e3o os c\u00f3digos mais prov\u00e1veis de acordar algu\u00e9m.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>500<\/td>\n<td>Internal Server Error<\/td>\n<\/tr>\n<tr>\n<td>501<\/td>\n<td>Not Implemented<\/td>\n<\/tr>\n<tr>\n<td>502<\/td>\n<td>Bad Gateway<\/td>\n<\/tr>\n<tr>\n<td>503<\/td>\n<td>Service Unavailable<\/td>\n<\/tr>\n<tr>\n<td>504<\/td>\n<td>Gateway Timeout<\/td>\n<\/tr>\n<tr>\n<td>505<\/td>\n<td>HTTP Version Not Supported<\/td>\n<\/tr>\n<tr>\n<td>506<\/td>\n<td>Variant Also Negotiates<\/td>\n<\/tr>\n<tr>\n<td>507<\/td>\n<td>Insufficient Storage<\/td>\n<\/tr>\n<tr>\n<td>508<\/td>\n<td>Loop Detected<\/td>\n<\/tr>\n<tr>\n<td>510<\/td>\n<td>Not Extended<\/td>\n<\/tr>\n<tr>\n<td>511<\/td>\n<td>Network Authentication Required<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='c\u00f3digos-n\u00e3o-padr\u00e3o-e-de-fornecedores'  id=\"boomdevs_26\">C\u00f3digos N\u00e3o Padr\u00e3o e de Fornecedores<\/h3>\n<p>Cloudflare, Nginx, Microsoft e Akamai retornam c\u00f3digos fora da especifica\u00e7\u00e3o oficial quando a camada de infraestrutura falha. Estes s\u00e3o os que voc\u00ea deve reconhecer de vista porque indicam que a falha est\u00e1 na borda, n\u00e3o na origem.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>C\u00f3digo<\/th>\n<th>Significado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>419<\/td>\n<td>Authentication Timeout<\/td>\n<\/tr>\n<tr>\n<td>420<\/td>\n<td>Enhance Your Calm \/ Method Failure<\/td>\n<\/tr>\n<tr>\n<td>440<\/td>\n<td>Login Timeout (Microsoft)<\/td>\n<\/tr>\n<tr>\n<td>444<\/td>\n<td>No Response (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>449<\/td>\n<td>Retry With (Microsoft)<\/td>\n<\/tr>\n<tr>\n<td>450<\/td>\n<td>Blocked by Windows Parental Controls<\/td>\n<\/tr>\n<tr>\n<td>460<\/td>\n<td>Client Closed Connection<\/td>\n<\/tr>\n<tr>\n<td>494<\/td>\n<td>Request Header Too Large (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>495<\/td>\n<td>SSL Certificate Error (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>496<\/td>\n<td>SSL Certificate Required (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>497<\/td>\n<td>HTTP Request Sent to HTTPS Port<\/td>\n<\/tr>\n<tr>\n<td>498<\/td>\n<td>Invalid Token<\/td>\n<\/tr>\n<tr>\n<td>499<\/td>\n<td>Client Closed Request (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>509<\/td>\n<td>Bandwidth Limit Exceeded<\/td>\n<\/tr>\n<tr>\n<td>520<\/td>\n<td>Unknown Error (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>521<\/td>\n<td>Web Server Is Down (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>522<\/td>\n<td>Connection Timed Out (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>523<\/td>\n<td>Origin Is Unreachable (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>524<\/td>\n<td>A Timeout Occurred (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>525<\/td>\n<td>SSL Handshake Failed (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>526<\/td>\n<td>Invalid SSL Certificate (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>527<\/td>\n<td>Railgun Error (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>529<\/td>\n<td>Site Overloaded<\/td>\n<\/tr>\n<tr>\n<td>530<\/td>\n<td>Site Frozen \/ Origin DNS Error<\/td>\n<\/tr>\n<tr>\n<td>561<\/td>\n<td>Unauthorized (Akamai)<\/td>\n<\/tr>\n<tr>\n<td>598<\/td>\n<td>Network Read Timeout<\/td>\n<\/tr>\n<tr>\n<td>599<\/td>\n<td>Network Connect Timeout<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Faixas de c\u00f3digos n\u00e3o listadas acima (104-199, 209-225, 227-299, 309-399, 432-450, 452-499, 512-599) s\u00e3o n\u00e3o atribu\u00eddas, depreciadas ou reservadas para uso de fornecedores. Trate qualquer c\u00f3digo nessas faixas como espec\u00edfico de fornecedor e consulte a documenta\u00e7\u00e3o da sua infraestrutura.<\/p>\n<h3 id='os-c\u00f3digos-que-seu-monitoramento-deve-realmente-alertar'  id=\"boomdevs_27\">Os C\u00f3digos Que Seu Monitoramento Deve Realmente Alertar<\/h3>\n<p>Dos 60+ c\u00f3digos acima, os que merecem limiares de alerta na maioria dos setups de produ\u00e7\u00e3o s\u00e3o uma lista bem mais curta:<\/p>\n<ul>\n<li><strong>200<\/strong>\u2014como um baseline. Uma queda s\u00fabita significa que algo mais est\u00e1 errado.<\/li>\n<li><strong>301, 302, 307, 308<\/strong>\u2014contagem de redirecionamentos. Picos podem significar roteamento mal configurado ou deploy que quebrou URLs can\u00f4nicos.<\/li>\n<li><strong>400<\/strong>\u2014requisi\u00e7\u00f5es malformadas. Geralmente mudan\u00e7a do lado consumidor.<\/li>\n<li><strong>401, 403<\/strong>\u2014falhas de autentica\u00e7\u00e3o e permiss\u00e3o. Frequentemente token, IAM ou altera\u00e7\u00e3o em WAF.<\/li>\n<li><strong>404<\/strong>\u2014recursos ausentes. Ru\u00eddo de fundo como casos isolados; problema de release em picos.<\/li>\n<li><strong>408<\/strong>\u2014timeouts do cliente. Vale alertar em taxas sustentadas; sinalizam chamadas downstream lentas.<\/li>\n<li><strong>429<\/strong>\u2014limite de taxa. Ou voc\u00ea est\u00e1 sendo throttled ou est\u00e1 throttleando algu\u00e9m.<\/li>\n<li><strong>500, 502, 503, 504<\/strong>\u2014falhas de aplica\u00e7\u00e3o, upstream, capacidade e timeout de gateway. Estes disparam pagina\u00e7\u00e3o on-call.<\/li>\n<li><strong>520-526<\/strong>\u2014falhas na borda do Cloudflare. Se estiver atr\u00e1s do Cloudflare, s\u00e3o sinais cr\u00edticos que isolam a falha no caminho borda-origem.<\/li>\n<\/ul>\n<p>Todo o resto vale registrar, mas raramente merece acordar algu\u00e9m.<\/p>\n<h2 id='como-verificar-o-c\u00f3digo-de-status-http-de-uma-p\u00e1gina'  id=\"boomdevs_28\">Como Verificar o C\u00f3digo de Status HTTP de uma P\u00e1gina<\/h2>\n<p>Antes de agir em um c\u00f3digo, voc\u00ea tem que v\u00ea-lo. Tr\u00eas maneiras, da mais r\u00e1pida para a mais completa.<\/p>\n<h3 id='no-chrome-devtools'  id=\"boomdevs_29\">No Chrome DevTools<\/h3>\n<ol>\n<li>Abra a p\u00e1gina.<\/li>\n<li>Clique com o bot\u00e3o direito em qualquer lugar e escolha Inspecionar, depois abra a aba Network.<\/li>\n<li>Recarregue. A primeira requisi\u00e7\u00e3o do documento mostra o c\u00f3digo na coluna Status.<\/li>\n<\/ol>\n<h3 id='na-linha-de-comando'  id=\"boomdevs_30\">Na Linha de Comando<\/h3>\n<p>Uma requisi\u00e7\u00e3o s\u00f3 com cabe\u00e7alho retorna a linha de status sem baixar o corpo:<\/p>\n<pre><code>curl -I https:\/\/example.com<\/code><\/pre>\n<p>A primeira linha da resposta \u00e9 o c\u00f3digo de status\u2014por exemplo, <code>HTTP\/2 200<\/code>.<\/p>\n<h3 id='em-escala'  id=\"boomdevs_31\">Em Escala<\/h3>\n<p>Checagens pontuais dizem o estado atual. N\u00e3o pegam falhas que ocorrem \u00e0s 3 da manh\u00e3 e somem antes de voc\u00ea acordar. Para falhas intermitentes, voc\u00ea precisa de checagens agendadas de v\u00e1rias regi\u00f5es\u2014o que <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/synthetic-monitoring\/\">monitoramento sint\u00e9tico<\/a> faz.<\/p>\n<h2 id='quando-um-200-ok-mente'  id=\"boomdevs_32\">Quando um 200 OK Mente<\/h2>\n<p>Um time de e-commerce \u00e9 acionado \u00e0s 11 da manh\u00e3 numa ter\u00e7a-feira. A convers\u00e3o caiu 80%. Eles conferem o dashboard de uptime. Todos os endpoints est\u00e3o verdes. Todos os c\u00f3digos de status s\u00e3o 200. Todas as regi\u00f5es reportam que o site est\u00e1 no ar.<\/p>\n<p>O site n\u00e3o est\u00e1 no ar. Um deploy 40 minutos antes enviou um bundle JavaScript que quebra a p\u00e1gina de checkout. O HTML renderiza, o servidor retorna 200, o monitor de c\u00f3digo de status v\u00ea 200, nenhum alerta dispara. Usu\u00e1rios veem carrinho vazio e saem.<\/p>\n<p>Este \u00e9 o modo de falha que o monitoramento puro de c\u00f3digo de status n\u00e3o consegue captar. A corre\u00e7\u00e3o \u00e9 em camadas:<\/p>\n<ul>\n<li><strong>Execute checagens em navegador real<\/strong> em caminhos cr\u00edticos do usu\u00e1rio\u2014home, busca, produto, carrinho, checkout. Navegadores reais executam o JavaScript e mostram erros no cliente que uma checagem estilo curl perde.<\/li>\n<li><strong>Observe sinais no corpo<\/strong>: presen\u00e7a de palavras-chave, visibilidade de elementos, estrutura esperada da resposta. N\u00e3o confie s\u00f3 no c\u00f3digo de status.<\/li>\n<li><strong>Vincule deploys ao monitoramento<\/strong>: qualquer checagem que fique vermelha em at\u00e9 15 minutos ap\u00f3s um release deve marcar o deploy automaticamente. Metade do tempo p\u00f3s-morte \u00e9 descobrir o que mudou; o sistema de monitoramento j\u00e1 sabe.<\/li>\n<\/ul>\n<h3 id='o-que-\u00e9-um-soft-404'  id=\"boomdevs_33\">O Que \u00c9 um Soft 404?<\/h3>\n<p>Uma vers\u00e3o desse problema tem nome: soft 404. Um soft 404 \u00e9 uma p\u00e1gina que retorna 200 OK mas avisa ao usu\u00e1rio que o conte\u00fado n\u00e3o existe\u2014uma mensagem &#8220;p\u00e1gina n\u00e3o encontrada&#8221; servida com c\u00f3digo de sucesso. A orienta\u00e7\u00e3o do Google \u00e9 retornar um 404 ou 410 real, pois soft 404s desperdi\u00e7am or\u00e7amento de crawl e confundem o \u00edndice sobre quais p\u00e1ginas s\u00e3o reais.<\/p>\n<p>Monitoramento puro por c\u00f3digo n\u00e3o pega soft 404, pela mesma raz\u00e3o que deixa passar checkout quebrado: o c\u00f3digo diz 200. Checagens em navegador real com valida\u00e7\u00f5es no corpo\u2014procurando o conte\u00fado real esperado ou a aus\u00eancia da string &#8220;not found&#8221;\u2014pegam.<\/p>\n<h2 id='como-c\u00f3digos-http-afetam-seo'  id=\"boomdevs_34\">Como C\u00f3digos HTTP Afetam SEO<\/h2>\n<p>Motores de busca usam c\u00f3digos de status para decidir o que rastrear, o que indexar, e com que frequ\u00eancia voltar. Tr\u00eas padr\u00f5es importam:<\/p>\n<ul>\n<li><strong>C\u00f3digos 4xx corroem o \u00edndice ao longo do tempo.<\/strong> Uma p\u00e1gina que retorna 404 por v\u00e1rias tentativas de crawl \u00e9 removida. Se voc\u00ea apagar uma p\u00e1gina, redirecione com 301 em vez de deixar 404.<\/li>\n<li><strong>C\u00f3digos 5xx desaceleram o rastreamento e prejudicam rankings.<\/strong> Googlebot interpreta 5xx persistentes como &#8220;este site est\u00e1 doente.&#8221; A taxa de rastreamento cai, indexa\u00e7\u00e3o desacelera, rankings podem cair.<\/li>\n<li><strong>301 vs 302 importa.<\/strong> 301 passa autoridade de link. 302 \u00e9 tratado como tempor\u00e1rio e pode n\u00e3o passar. Se mudan\u00e7a for permanente, escolha 301.<\/li>\n<\/ul>\n<p>A conclus\u00e3o pr\u00e1tica: erros 5xx n\u00e3o s\u00e3o s\u00f3 problema de disponibilidade. S\u00e3o problema de SEO que se agrava quanto mais persistem. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/website-monitoring-errors-dns-tcp-tls-http\/\">Erros DNS, TCP, TLS e HTTP<\/a> t\u00eam custos SEO diferentes\u2014saber em qual camada o erro ocorre ajuda voc\u00ea a triagem mais r\u00e1pido.<\/p>\n<figure id=\"attachment_33963\" aria-describedby=\"caption-attachment-33963\" style=\"width: 1536px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-33963\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart.webp\" alt=\"Fluxograma de decis\u00e3o para triagem de alertas de c\u00f3digo de status HTTP\u2014qual camada checar primeiro, quando acionar on-call, quando reverter deploy\" width=\"1536\" height=\"1024\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-768x512.webp 768w\" sizes=\"(max-width: 1536px) 100vw, 1536px\" \/><figcaption id=\"caption-attachment-33963\" class=\"wp-caption-text\">Um caminho de triagem simples do c\u00f3digo de status ao primeiro passo de investiga\u00e7\u00e3o.<\/figcaption><\/figure>\n<h2 id='monitorando-c\u00f3digos-de-status-http-sem-afundar-em-alertas'  id=\"boomdevs_35\">Monitorando C\u00f3digos de Status HTTP Sem Afundar em Alertas<\/h2>\n<p>Todo time que monitora tr\u00e1fego HTTP \u00e0s vezes enfrenta o mesmo problema: alertas demais, sinal de menos. Alguns h\u00e1bitos mant\u00eam o monitoramento de c\u00f3digo de status \u00fatil em vez de ruidoso.<\/p>\n<p><strong>Alerta por taxas, n\u00e3o por requisi\u00e7\u00f5es \u00fanicas.<\/strong> Um 500 \u00e9 ru\u00eddo. Cinquenta 500 em cinco minutos \u00e9 incidente. Configure limiares baseados no volume de tr\u00e1fego baseline.<\/p>\n<p><strong>Separe endpoints p\u00fablicos dos internos.<\/strong> Um 500 na API de checkout deve alertar. Um 500 num endpoint administrativo pouco usado pode esperar hor\u00e1rio comercial.<\/p>\n<p><strong>Teste de onde seus usu\u00e1rios est\u00e3o.<\/strong> Uma checagem de um data center n\u00e3o pega falha espec\u00edfica regional do CDN. Use rede de monitoramento com m\u00faltiplas geografias para detectar problemas locais antes dos clientes.<\/p>\n<p><strong>Combine checagens de status com checagens de conte\u00fado.<\/strong> 200 OK \u00e9 ponto de partida, n\u00e3o linha de chegada. Valide que a resposta tem o que deve ter.<\/p>\n<p>O <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/monitoramento-de-aplicativos-web\/\">monitoramento de aplica\u00e7\u00f5es web<\/a> da Dotcom-Monitor trata todos os quatro: alerta por taxa, segmenta\u00e7\u00e3o de endpoints, locais globais de monitoramento, e checagens de conte\u00fado em navegador real. Para stacks focadas em API, o caminho de <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/web-api-monitoring\/\">monitoramento de API<\/a> adiciona valida\u00e7\u00e3o de esquema e SLOs de tempo de resposta em cima de checagens por c\u00f3digo de status. Ambos alimentam o mesmo <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/recursos-alertas\/\">pipeline de alertas<\/a> para voc\u00ea n\u00e3o montar sinais de tr\u00eas vendors diferentes.<\/p>\n<h2 id='considera\u00e7\u00f5es-finais'  id=\"boomdevs_36\">Considera\u00e7\u00f5es Finais<\/h2>\n<p>Os c\u00f3digos de status HTTP mais comuns n\u00e3o mudaram em anos. 200, 301, 404, 500, 502, 503\u2014voc\u00ea ver\u00e1 todos esta semana. O que muda \u00e9 a velocidade com que seu time passa de &#8220;vi o c\u00f3digo&#8221; para &#8220;consertei a causa.&#8221;<\/p>\n<p>Essa lacuna \u00e9 onde um bom monitoramento compensa. S\u00f3 c\u00f3digos dizem que algo ocorreu. Checagens em camadas\u2014status, conte\u00fado, navegador real, multi-regi\u00e3o\u2014dizem o que, onde, e o que fazer a seguir.<\/p>\n<p>Se quiser ver como \u00e9, a <a href=\"https:\/\/www.dotcom-monitor.com\/\">Dotcom-Monitor<\/a> oferece teste gratuito. Aponte para um dos seus endpoints e veja o que aparece.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Uma refer\u00eancia pr\u00e1tica para engenheiros que recebem chamadas quando esses c\u00f3digos aparecem.<\/p>\n","protected":false},"author":21,"featured_media":33975,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5177],"tags":[],"class_list":["post-18002","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dicas-tecnicas-de-desempenho"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/18002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=18002"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/18002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/33975"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=18002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=18002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=18002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}