{"id":12264,"date":"2020-05-26T09:21:11","date_gmt":"2020-05-26T09:21:11","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/05\/26\/los-10-most-common-http-status-codes\/"},"modified":"2026-05-31T20:27:25","modified_gmt":"2026-05-31T20:27:25","slug":"los-10-most-common-http-status-codes","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/los-10-most-common-http-status-codes\/","title":{"rendered":"Los c\u00f3digos de estado HTTP m\u00e1s comunes (y qu\u00e9 hacer con cada uno)"},"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=\"Referencia visual de los c\u00f3digos de estado HTTP m\u00e1s comunes agrupados por categor\u00eda\u20142xx \u00e9xito, 3xx redirecci\u00f3n, 4xx error del cliente, 5xx error del 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\">Las cinco categor\u00edas de c\u00f3digos de estado HTTP y los c\u00f3digos que realmente ver\u00e1s en producci\u00f3n.<\/figcaption><\/figure>\n<p>Tu buscapersonas suena a las 2 a.m. La carga \u00fatil de la alerta tiene un c\u00f3digo de estado. Lo que haces a continuaci\u00f3n depende casi por completo del c\u00f3digo que veas.<\/p>\n<p>Esa es la parte que la mayor\u00eda de las gu\u00edas de c\u00f3digos de estado HTTP omiten. Listan definiciones, clasifican los c\u00f3digos en cinco grupos y paran. \u00datil como glosario, menos \u00fatil cuando un endpoint real est\u00e1 lanzando 502s y un ejecutivo pregunta por qu\u00e9 el checkout est\u00e1 roto.<\/p>\n<p>Esta gu\u00eda cubre los mismos diez c\u00f3digos que ver\u00e1s con mayor frecuencia, adem\u00e1s de algunas menciones honor\u00edficas. Para cada uno: qu\u00e9 significa, qu\u00e9 suele desencadenarlo en producci\u00f3n y qu\u00e9 revisar primero. El objetivo es acortar el tiempo entre &#8220;Veo el c\u00f3digo&#8221; y &#8220;S\u00e9 qu\u00e9 arreglar.&#8221;<\/p>\n<h2 id='qu\u00e9-es-un-c\u00f3digo-de-estado-http'  id=\"boomdevs_1\">\u00bfQu\u00e9 es un c\u00f3digo de estado HTTP?<\/h2>\n<p>Un c\u00f3digo de estado HTTP es un n\u00famero de tres d\u00edgitos que el servidor env\u00eda con cada respuesta. Indica al cliente si la solicitud fue exitosa, fallida o necesita ser redirigida. Los ves en todas partes: en la pesta\u00f1a Network de las DevTools de tu navegador, en los registros del balanceador de carga, en alertas de monitoreo, en paneles de CDN. Esta gu\u00eda se enfoca en los que realmente despiertan a la gente.<\/p>\n<h2 id='las-cinco-categor\u00edas-de-c\u00f3digos-de-estado-http'  id=\"boomdevs_2\">Las cinco categor\u00edas de c\u00f3digos de estado HTTP<\/h2>\n<p>El primer d\u00edgito del c\u00f3digo indica la clase de respuesta:<\/p>\n<ul>\n<li><strong>1xx Informativos.<\/strong> Raros en el trabajo cotidiano. Principalmente usados para negociaci\u00f3n de protocolo (100 Continue, 101 Switching Protocols para actualizaciones WebSocket).<\/li>\n<li><strong>2xx \u00c9xito.<\/strong> La solicitud funcion\u00f3. 200 es el predeterminado; 201 significa que se cre\u00f3 un recurso; 204 significa \u00e9xito sin cuerpo.<\/li>\n<li><strong>3xx Redirecci\u00f3n.<\/strong> El recurso vive en otro lugar. Los navegadores y rastreadores siguen estas autom\u00e1ticamente hasta un l\u00edmite.<\/li>\n<li><strong>4xx Error del cliente.<\/strong> La solicitud fue incorrecta. URL mala, falta de autenticaci\u00f3n, permisos bloqueados, carga \u00fatil mal formada.<\/li>\n<li><strong>5xx Error del servidor.<\/strong> La solicitud estaba bien. El servidor no pudo cumplirla.<\/li>\n<\/ul>\n<p>La divisi\u00f3n entre 4xx y 5xx es lo que m\u00e1s importa para el triaje. Un 4xx indica &#8220;el que llama hizo algo mal.&#8221; Un 5xx indica &#8220;nosotros hicimos algo mal.&#8221; El primero va a quien llam\u00f3 el endpoint. El segundo va a ti.<\/p>\n<p>Para una enumeraci\u00f3n completa, la <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/http-status-codes-list\/\">referencia completa de c\u00f3digos de estado HTTP<\/a> del wiki de Dotcom-Monitor lista todos los c\u00f3digos definidos en la especificaci\u00f3n. El resto de esta gu\u00eda se enfoca en los que realmente aparecen en alertas.<\/p>\n<h2 id='los-diez-c\u00f3digos-de-estado-http-m\u00e1s-comunes'  id=\"boomdevs_3\">Los diez c\u00f3digos de estado HTTP m\u00e1s comunes<\/h2>\n<h3 id='200-ok'  id=\"boomdevs_4\">200 OK<\/h3>\n<p>El servidor proces\u00f3 la solicitud y devolvi\u00f3 la respuesta esperada. Este es el c\u00f3digo que quieres ver en la gran mayor\u00eda de las solicitudes a un sitio productivo sano.<\/p>\n<p><strong>Cuidado con:<\/strong> un 200 OK no es prueba de que la p\u00e1gina sea correcta. JavaScript puede fallar silenciosamente y mostrar una p\u00e1gina en blanco. Un API puede devolver 200 con un cuerpo de error. Un formulario de login puede mostrar &#8220;credenciales inv\u00e1lidas&#8221; dentro de una respuesta 200. Las verificaciones solo por c\u00f3digo de estado no detectan esto. Comb\u00ednalas con verificaciones en navegador real (m\u00e1s sobre esto abajo).<\/p>\n<h3 id='301-moved-permanently'  id=\"boomdevs_5\">301 Moved Permanently<\/h3>\n<p>El recurso tiene una nueva URL permanente. Los navegadores almacenan en cach\u00e9 la redirecci\u00f3n agresivamente. Los motores de b\u00fasqueda transfieren la mayor\u00eda de la equidad del enlace al destino.<\/p>\n<p><strong>\u00dasalo para:<\/strong> cambios de URL tras una migraci\u00f3n, cambiar HTTP a HTTPS, consolidar rutas duplicadas, retirar slugs antiguos. Una vez que un 301 est\u00e1 activo y cacheado, revertirlo es doloroso\u2014los navegadores y rastreadores seguir\u00e1n yendo a la nueva ubicaci\u00f3n durante semanas.<\/p>\n<h3 id='302-found-redirecci\u00f3n-temporal'  id=\"boomdevs_6\">302 Found (Redirecci\u00f3n Temporal)<\/h3>\n<p>El recurso est\u00e1 temporalmente en otro lugar. Los navegadores no almacenan en cach\u00e9 la redirecci\u00f3n, y los motores de b\u00fasqueda no pasan toda la equidad del enlace.<\/p>\n<p><strong>Cuidado con:<\/strong> el 302 est\u00e1 sobreusado. Los equipos lo usan porque la funci\u00f3n de redirecci\u00f3n por defecto del framework devuelve 302. Si el cambio es permanente, usa 301. Si necesitas preservar el m\u00e9todo HTTP (un POST sigue siendo POST), usa 307 o 308 en su lugar. Google eventualmente tratar\u00e1 los 302 persistentes como 301, pero &#8220;eventualmente&#8221; no es una estrategia.<\/p>\n<h3 id='400-bad-request'  id=\"boomdevs_7\">400 Bad Request<\/h3>\n<p>El servidor no puede analizar la solicitud. JSON mal formado, cabeceras inv\u00e1lidas, cargas \u00fatiles demasiado grandes, violaciones de esquema.<\/p>\n<p><strong>Revisa primero:<\/strong> el cuerpo de la solicitud. Un aumento de 400 en un endpoint API suele indicar que un cliente comenz\u00f3 a enviar datos con formato incorrecto\u2014un despliegue en el lado consumidor, un cambio de esquema en el tuyo, o una integraci\u00f3n de terceros que actualiz\u00f3 su formato. Compara la carga \u00fatil de la solicitud con tu \u00faltima versi\u00f3n conocida correcta.<\/p>\n<h3 id='401-unauthorized'  id=\"boomdevs_8\">401 Unauthorized<\/h3>\n<p>La solicitud no tiene credenciales o las credenciales fueron rechazadas. El nombre es enga\u00f1oso\u2014el problema es autenticaci\u00f3n, no autorizaci\u00f3n.<\/p>\n<p><strong>Revisa primero:<\/strong> los tokens. Un pico repentino de 401 en endpoints que funcionaban suele significar que un token expir\u00f3, una clave de firma fue rotada, un proveedor OIDC tuvo una ca\u00edda o alguien cambi\u00f3 el claim de audience. Si tu <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/api-availability-monitoring\/\">monitoreo de disponibilidad API<\/a> muestra 401s donde antes hab\u00eda 200s, usualmente la capa de autenticaci\u00f3n es la culpable.<\/p>\n<h3 id='403-forbidden'  id=\"boomdevs_9\">403 Forbidden<\/h3>\n<p>Las credenciales son v\u00e1lidas, pero el que llama no tiene permiso para acceder a este recurso. El problema es autorizaci\u00f3n, no autenticaci\u00f3n.<\/p>\n<p><strong>Revisa primero:<\/strong> permisos y reglas de infraestructura. Los 403 aparecen cuando una pol\u00edtica IAM cambia, una regla WAF comienza a bloquear tr\u00e1fico leg\u00edtimo, una pol\u00edtica de acceso CDN es demasiado agresiva o un feature flag cambia para un segmento de usuarios incorrecto. Si los 403 empezaron justo despu\u00e9s de un despliegue, revisa diferencias de pol\u00edticas y configuraciones antes del c\u00f3digo de la app.<\/p>\n<h3 id='404-not-found'  id=\"boomdevs_10\">404 Not Found<\/h3>\n<p>El servidor entendi\u00f3 la solicitud pero no tiene recurso en esa URL. El c\u00f3digo de estado m\u00e1s famoso que existe.<\/p>\n<p><strong>Dos escenarios a diferenciar:<\/strong><\/p>\n<ul>\n<li><strong>404 puntuales<\/strong> por errores tipogr\u00e1ficos, antiguos marcadores o rastreadores buscando vulnerabilidades. Son ruido de fondo.<\/li>\n<li><strong>Un estallido de 404 en URLs can\u00f3nicas<\/strong> justo tras un despliegue. Eso es una versi\u00f3n rota\u2014se eliminaron rutas, falta un artefacto de build o alguien despleg\u00f3 un cambio de slug sin redirecciones. Revertir o aplicar un parche r\u00e1pido.<\/li>\n<\/ul>\n<p>Los 404 persistentes en p\u00e1ginas indexadas eventualmente ser\u00e1n eliminados por Google, por lo que las p\u00e1ginas can\u00f3nicas que lanzan 404 tambi\u00e9n tienen un costo SEO.<\/p>\n<h4 id='soluci\u00f3n'  id=\"boomdevs_11\">Soluci\u00f3n<\/h4>\n<p><strong>Camino r\u00e1pido:<\/strong> si la p\u00e1gina se movi\u00f3, a\u00f1ade una redirecci\u00f3n 301 de la URL antigua a la nueva para que usuarios y rastreadores lleguen al lugar correcto. Si la p\u00e1gina ya no existe, devuelve un 404 o 410 real en lugar de una redirecci\u00f3n vaga a la p\u00e1gina principal.<\/p>\n<p><strong>Soluci\u00f3n real:<\/strong> audita la fuente de los 404. Los enlaces internos rotos se arreglan en la fuente; las rutas faltantes tras un despliegue se corrigen con un parche; una mala migraci\u00f3n que elimin\u00f3 slugs necesita un mapa de redirecciones. Rastrea tu propio sitio peri\u00f3dicamente para encontrar enlaces muertos antes que Google.<\/p>\n<h3 id='500-internal-server-error'  id=\"boomdevs_12\">500 Internal Server Error<\/h3>\n<p>El servidor encontr\u00f3 una excepci\u00f3n no manejada. El 5xx comod\u00edn. Te dice que algo fall\u00f3 pero no qu\u00e9.<\/p>\n<p><strong>Revisa primero:<\/strong> los logs de la aplicaci\u00f3n. Cada 500 tiene un stack trace en alg\u00fan lugar\u2014si no, tu logging necesita mejora antes que tu c\u00f3digo. Desencadenantes comunes: excepci\u00f3n no capturada en una ruta desplegada recientemente, dependencia downstream que devuelve un formato inesperado, pool de conexiones a base de datos agotado, un ciclo de reinicio por falta de memoria. Un pico sostenido de 500 en un endpoint productivo debe notificar a on-call.<\/p>\n<h4 id='soluci\u00f3n-1'  id=\"boomdevs_13\">Soluci\u00f3n<\/h4>\n<p><strong>Camino r\u00e1pido:<\/strong> si el pico comenz\u00f3 justo tras un despliegue, revierte. Un 500 que aparece minutos despu\u00e9s de un deploy es el deploy hasta que se demuestre lo contrario.<\/p>\n<p><strong>Soluci\u00f3n real:<\/strong> lee el stack trace y corrige la ruta de c\u00f3digo que falla, luego a\u00f1ade un test de regresi\u00f3n para evitar que regrese. Si el desencadenante fue un l\u00edmite de recurso\u2014pool de conexiones, memoria, manejadores de archivos\u2014aumenta el l\u00edmite y a\u00f1ade una alerta antes de que se alcance la pr\u00f3xima vez.<\/p>\n<h3 id='502-bad-gateway'  id=\"boomdevs_14\">502 Bad Gateway<\/h3>\n<p>Un proxy, balanceador de carga o CDN recibi\u00f3 una respuesta inv\u00e1lida del servidor upstream. El proxy mismo est\u00e1 saludable. Lo que est\u00e1 detr\u00e1s no.<\/p>\n<p><strong>Revisa primero:<\/strong> la salud del upstream. Desencadenantes comunes: un contenedor de app se cay\u00f3 y el balanceador sigue enviando tr\u00e1fico, el upstream tarda demasiado en responder, un pod de Kubernetes est\u00e1 en CrashLoopBackOff, un trabajador Nginx est\u00e1 mal configurado, o la conexi\u00f3n entre proxy y upstream se reinici\u00f3. El 502 es uno de los c\u00f3digos con se\u00f1al m\u00e1s alta en arquitecturas en capas\u2014te dice que el borde est\u00e1 bien y el problema est\u00e1 a un salto.<\/p>\n<h4 id='soluci\u00f3n-2'  id=\"boomdevs_15\">Soluci\u00f3n<\/h4>\n<p><strong>Camino r\u00e1pido:<\/strong> reinicia o reemplaza la instancia upstream no saludable y confirma que las verificaciones de salud del balanceador realmente sacan nodos muertos de la rotaci\u00f3n.<\/p>\n<p><strong>Soluci\u00f3n real:<\/strong> encuentra por qu\u00e9 el upstream devolvi\u00f3 basura. Revisa si el timeout del proxy es m\u00e1s corto que el tiempo real de respuesta del upstream, si el pod est\u00e1 en un ciclo de crashes al iniciar, y si las configuraciones de keep-alive coinciden en ambos lados de la conexi\u00f3n.<\/p>\n<h3 id='503-service-unavailable'  id=\"boomdevs_16\">503 Service Unavailable<\/h3>\n<p>El servidor est\u00e1 temporalmente incapaz de manejar la solicitud. Capacidad agotada, modo mantenimiento, autoscaler a\u00fan arrancando.<\/p>\n<p><strong>Revisa primero:<\/strong> saturaci\u00f3n de recursos y l\u00edmites de tasa. Los 503 durante un pico de tr\u00e1fico suelen significar que el autoscaler no da abasto o que llegaste a un l\u00edmite de conexiones. Los 503 en estado estable suelen indicar que un proceso est\u00e1 en modo mantenimiento o una cola est\u00e1 saturada. Algunas plataformas tambi\u00e9n devuelven 503 cuando un WAF upstream o sistema anti-bots limita por tasa a un llamador\u2014vale la pena comprobar antes de asumir que el problema es la app.<\/p>\n<h4 id='soluci\u00f3n-3'  id=\"boomdevs_17\">Soluci\u00f3n<\/h4>\n<p><strong>Camino r\u00e1pido:<\/strong> devuelve el 503 con un encabezado <code>Retry-After<\/code> para que clientes bien comportados y rastreadores se retiren en lugar de golpear un servidor saturado. En PHP:<\/p>\n<pre><code>http_response_code(503);\nheader('Retry-After: 60');<\/code><\/pre>\n<p><strong>Soluci\u00f3n real:<\/strong> encuentra el recurso saturado\u2014conexiones a base de datos, pool de trabajadores, l\u00edmite del autoscaler\u2014y elimina el cuello de botella. Si el 503 viene de un l\u00edmite de tasa de CDN o WAF, aumenta el l\u00edmite o pon en lista blanca al llamador leg\u00edtimo.<\/p>\n<h2 id='otros-c\u00f3digos-que-vale-la-pena-conocer'  id=\"boomdevs_18\">Otros c\u00f3digos que vale la pena conocer<\/h2>\n<p>Los diez anteriores cubren la mayor\u00eda del tr\u00e1fico en producci\u00f3n. Pero hay algunos otros que aparecen lo suficientemente seguido en incidentes reales que los ingenieros on-call deber\u00edan reconocerlos al instante.<\/p>\n<ul>\n<li><strong>304 Not Modified.<\/strong> Enviado cuando un recurso cacheado sigue fresco. Com\u00fan en tr\u00e1fico con CDN delante. Una disminuci\u00f3n de 304 puede significar que tus encabezados cache-control cambiaron y est\u00e1s pagando por ancho de banda de origen que antes ahorrabas.<\/li>\n<li><strong>307 Temporary Redirect.<\/strong> Como 302, pero preserva el m\u00e9todo HTTP. Un POST sigue siendo POST. Usa 307 en lugar de 302 cuando redirijas env\u00edos de formulario o llamadas API no idempotentes.<\/li>\n<li><strong>308 Permanent Redirect.<\/strong> Como 301, pero preserva el m\u00e9todo HTTP. La opci\u00f3n moderna para redireccionar permanentemente endpoints API que manejan POST, PUT, PATCH o DELETE.<\/li>\n<li><strong>429 Too Many Requests.<\/strong> Se alcanz\u00f3 l\u00edmite de tasa. O te est\u00e1n throttling con un API upstream o t\u00fa est\u00e1s limitando a alguien. Revisa los encabezados <code>Retry-After<\/code>; resp\u00e9talos.<\/li>\n<li><strong>504 Gateway Timeout.<\/strong> Un proxy desisti\u00f3 de esperar al upstream. Diferente de 502 en que el upstream no devolvi\u00f3 una mala respuesta, sino ninguna respuesta a tiempo. Usualmente una consulta larga, un worker congelado o un API downstream lento.<\/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>Los cuatro c\u00f3digos de redirecci\u00f3n se confunden constantemente. La diferencia se reduce a dos cosas: si el movimiento es permanente y si el m\u00e9todo HTTP se mantiene tras la redirecci\u00f3n.<\/p>\n<div class=\"table-wrap\">\n<table class=\"compare\">\n<thead>\n<tr>\n<th>Comportamiento<\/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>Perdurabilidad<\/td>\n<td>Permanente<\/td>\n<td>Temporal<\/td>\n<td>Temporal<\/td>\n<td>Permanente<\/td>\n<\/tr>\n<tr>\n<td>M\u00e9todo preservado<\/td>\n<td>No garantizado<\/td>\n<td>No garantizado<\/td>\n<td>S\u00ed<\/td>\n<td>S\u00ed<\/td>\n<\/tr>\n<tr>\n<td>Cacheado por navegadores<\/td>\n<td>Agresivamente<\/td>\n<td>No<\/td>\n<td>No<\/td>\n<td>S\u00ed<\/td>\n<\/tr>\n<tr>\n<td>Equidad de enlace transmitida<\/td>\n<td>Mayormente<\/td>\n<td>Limitada<\/td>\n<td>Limitada<\/td>\n<td>Mayormente<\/td>\n<\/tr>\n<tr>\n<td>Uso cuando<\/td>\n<td>Movimiento permanente de URL<\/td>\n<td>Cambio temporal<\/td>\n<td>Redirecci\u00f3n de formulario o POST<\/td>\n<td>Endpoint API movido permanentemente<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Para una p\u00e1gina simple que se movi\u00f3 permanentemente, usa 301. Cuando la redirecci\u00f3n debe mantener un POST como POST\u2014un env\u00edo de formulario o llamada API no idempotente\u2014usa 307 si es temporal o 308 si es permanente.<\/p>\n<h2 id='la-referencia-completa-de-c\u00f3digos-de-estado-http'  id=\"boomdevs_20\">La referencia completa de c\u00f3digos de estado HTTP<\/h2>\n<p>Los c\u00f3digos arriba cubren casi todo lo que genera una alerta real. Para los inusuales\u2014los c\u00f3digos que aparecen una vez por trimestre y te hacen detenerte a buscar algo\u2014aqu\u00ed est\u00e1 la lista est\u00e1ndar completa, m\u00e1s los c\u00f3digos no est\u00e1ndar que ver\u00e1s de proveedores comunes de infraestructura.<\/p>\n<h3 id='1xx-informativos'  id=\"boomdevs_21\">1xx Informativos<\/h3>\n<p>El servidor ha recibido la solicitud y contin\u00faa proces\u00e1ndola. Raramente ver\u00e1s estos en logs de aplicaci\u00f3n porque la mayor\u00eda de clientes y proxies los manejan transparentemente.<\/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-\u00e9xito'  id=\"boomdevs_22\">2xx \u00c9xito<\/h3>\n<p>La solicitud fue recibida, entendida y aceptada. 200 es el caballo de batalla; el resto importan cuando construyes APIs o trabajas con contenido parcial, WebDAV o operaciones batch.<\/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-redirecci\u00f3n'  id=\"boomdevs_23\">3xx Redirecci\u00f3n<\/h3>\n<p>El recurso vive en otra parte, o la copia cacheada sigue vigente. 301 y 302 dominan; el resto importan para APIs (307\/308 preservan el m\u00e9todo HTTP) y pipelines de cacheo (304 ahorra ancho de banda al origen).<\/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-errores-del-cliente'  id=\"boomdevs_24\">4xx Errores del cliente<\/h3>\n<p>La solicitud fue incorrecta. La mayor\u00eda nunca los ver\u00e1s; la media docena com\u00fan aparece a diario. Vale la pena saber que existen los raros para no perder tiempo adivinando cuando caen un 418 o 451 en un 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-errores-del-servidor'  id=\"boomdevs_25\">5xx Errores del servidor<\/h3>\n<p>La solicitud estaba bien. Algo en el servidor fall\u00f3. Estos son los c\u00f3digos que m\u00e1s probablemente despertar\u00e1n a alguien.<\/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-no-est\u00e1ndar-y-de-proveedores'  id=\"boomdevs_26\">C\u00f3digos no est\u00e1ndar y de proveedores<\/h3>\n<p>Cloudflare, Nginx, Microsoft y Akamai devuelven c\u00f3digos fuera de la especificaci\u00f3n oficial cuando su capa de infraestructura falla. Estos son los c\u00f3digos que debes reconocer al instante porque indican que la falla est\u00e1 en el borde, no en tu origen.<\/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>Los rangos de c\u00f3digos no listados arriba (104-199, 209-225, 227-299, 309-399, 432-450, 452-499, 512-599) son no asignados, obsoletos o reservados para uso del proveedor. Trata cualquier c\u00f3digo en esos rangos como espec\u00edfico de proveedor y verifica la documentaci\u00f3n de tu infraestructura.<\/p>\n<h3 id='los-c\u00f3digos-que-tu-monitoreo-realmente-deber\u00eda-alertar'  id=\"boomdevs_27\">Los c\u00f3digos que tu monitoreo realmente deber\u00eda alertar<\/h3>\n<p>De los m\u00e1s de 60 c\u00f3digos anteriores, los que establecen umbrales de alerta en la mayor\u00eda de configuraciones productivas son una lista mucho m\u00e1s corta:<\/p>\n<ul>\n<li><strong>200<\/strong>\u2014como ratio base. Una ca\u00edda repentina indica que algo m\u00e1s est\u00e1 fallando.<\/li>\n<li><strong>301, 302, 307, 308<\/strong>\u2014conteos de redirecciones. Picos pueden indicar enrutamiento mal configurado o un despliegue que rompi\u00f3 URLs can\u00f3nicas.<\/li>\n<li><strong>400<\/strong>\u2014solicitudes mal formadas. Usualmente un cambio del consumidor.<\/li>\n<li><strong>401, 403<\/strong>\u2014fallos de autenticaci\u00f3n y permisos. Frecuentemente un cambio en token, IAM o WAF.<\/li>\n<li><strong>404<\/strong>\u2014recursos faltantes. Ruido de fondo como casos aislados; problema de lanzamiento en picos.<\/li>\n<li><strong>408<\/strong>\u2014time-outs del cliente. Vale la pena alertar en tasas sostenidas; se\u00f1ala llamadas lentas downstream.<\/li>\n<li><strong>429<\/strong>\u2014limitaci\u00f3n de tasa. O te throttlean o t\u00fa est\u00e1s limitando a alguien.<\/li>\n<li><strong>500, 502, 503, 504<\/strong>\u2014fallas de aplicaci\u00f3n, upstream, capacidad y timeout de gateway. Estos notifican a on-call.<\/li>\n<li><strong>520-526<\/strong>\u2014fallas en el borde de Cloudflare. Si est\u00e1s detr\u00e1s de Cloudflare, estos son se\u00f1ales cr\u00edticas porque a\u00edslan la falla al camino borde-origen.<\/li>\n<\/ul>\n<p>Todo lo dem\u00e1s vale la pena registrar pero rara vez merece despertar a alguien.<\/p>\n<h2 id='c\u00f3mo-revisar-el-c\u00f3digo-de-estado-http-de-una-p\u00e1gina'  id=\"boomdevs_28\">C\u00f3mo revisar el c\u00f3digo de estado HTTP de una p\u00e1gina<\/h2>\n<p>Antes de actuar sobre un c\u00f3digo, debes verlo. Tres formas, de la m\u00e1s r\u00e1pida a la m\u00e1s completa.<\/p>\n<h3 id='en-chrome-devtools'  id=\"boomdevs_29\">En Chrome DevTools<\/h3>\n<ol>\n<li>Abre la p\u00e1gina.<\/li>\n<li>Haz clic derecho en cualquier parte y elige Inspeccionar, luego abre la pesta\u00f1a Network.<\/li>\n<li>Recarga. La primera solicitud de documento muestra el c\u00f3digo en la columna Status.<\/li>\n<\/ol>\n<h3 id='desde-la-l\u00ednea-de-comandos'  id=\"boomdevs_30\">Desde la l\u00ednea de comandos<\/h3>\n<p>Una solicitud solo de encabezados devuelve la l\u00ednea de estado sin descargar el cuerpo:<\/p>\n<pre><code>curl -I https:\/\/example.com<\/code><\/pre>\n<p>La primera l\u00ednea de la respuesta es el c\u00f3digo de estado\u2014por ejemplo, <code>HTTP\/2 200<\/code>.<\/p>\n<h3 id='a-escala'  id=\"boomdevs_31\">A escala<\/h3>\n<p>Las verificaciones puntuales te dicen el estado actual. No atrapar\u00e1n la falla que ocurre a las 3 a.m. y se resuelve antes de que despiertes. Para detectar fallas intermitentes, necesitas verificaciones programadas desde m\u00faltiples regiones\u2014que es lo que hace el <a href=\"https:\/\/www.dotcom-monitor.com\/es\/soluciones\/synthetic-monitoring\/\">monitoreo sint\u00e9tico<\/a>.<\/p>\n<h2 id='cuando-un-200-ok-miente'  id=\"boomdevs_32\">Cuando un 200 OK miente<\/h2>\n<p>Un equipo de comercio electr\u00f3nico recibe una alerta a las 11 a.m. de un martes. La conversi\u00f3n baj\u00f3 un 80%. Revisan su panel de uptime. Todos los endpoints est\u00e1n verdes. Todos los c\u00f3digos de estado son 200. Todas las regiones reportan que el sitio est\u00e1 activo.<\/p>\n<p>El sitio no est\u00e1 activo. Un despliegue 40 minutos antes lanz\u00f3 un bundle de JavaScript que falla en la p\u00e1gina de checkout. El HTML se carga, el servidor devuelve 200, el monitor de c\u00f3digo de estado ve 200, no hay alerta. Los usuarios ven un carrito vac\u00edo y se van.<\/p>\n<p>Este es el modo de falla que la monitorizaci\u00f3n pura de c\u00f3digos de estado no puede detectar. La soluci\u00f3n es en capas:<\/p>\n<ul>\n<li><strong>Ejecutar verificaciones con navegador real<\/strong> en caminos cr\u00edticos de usuario\u2014home, b\u00fasqueda, producto, carrito, checkout. Los navegadores reales ejecutan JavaScript y muestran errores del lado cliente que una verificaci\u00f3n estilo curl no ve.<\/li>\n<li><strong>Vigilar se\u00f1ales a nivel de cuerpo<\/strong>: presencia de palabras clave, visibilidad de elementos, estructura esperada de respuesta. No conf\u00edes solo en el c\u00f3digo de estado.<\/li>\n<li><strong>Relacionar despliegues con monitoreo<\/strong>: cualquier verificaci\u00f3n que pase de verde a rojo en 15 minutos tras un release debe autoetiquetar el despliegue. La mitad del tiempo post-mortem es descubrir qu\u00e9 cambi\u00f3; el sistema de monitoreo ya lo sabe.<\/li>\n<\/ul>\n<h3 id='qu\u00e9-es-un-soft-404'  id=\"boomdevs_33\">\u00bfQu\u00e9 es un soft 404?<\/h3>\n<p>Una versi\u00f3n de este problema tiene nombre: el soft 404. Un soft 404 es una p\u00e1gina que devuelve 200 OK mientras informa al usuario que el contenido no existe\u2014un mensaje de &#8220;p\u00e1gina no encontrada&#8221; servido con c\u00f3digo de \u00e9xito. La gu\u00eda de Google es devolver un 404 o 410 real en su lugar, porque los soft 404s desperdician el presupuesto de rastreo y confunden al \u00edndice sobre qu\u00e9 p\u00e1ginas son reales.<\/p>\n<p>La monitorizaci\u00f3n pura por c\u00f3digo de estado no captar\u00e1 un soft 404, por la misma raz\u00f3n que falla con un checkout roto: el c\u00f3digo dice 200. Las verificaciones con navegador real y aserciones en el cuerpo\u2014buscando el contenido real esperado o la ausencia de un texto &#8220;no encontrado&#8221;\u2014s\u00ed lo har\u00e1n.<\/p>\n<h2 id='c\u00f3mo-afectan-los-c\u00f3digos-de-estado-http-al-seo'  id=\"boomdevs_34\">C\u00f3mo afectan los c\u00f3digos de estado HTTP al SEO<\/h2>\n<p>Los motores de b\u00fasqueda usan c\u00f3digos de estado para decidir qu\u00e9 rastrear, qu\u00e9 indexar y con qu\u00e9 frecuencia volver. Tres patrones importan:<\/p>\n<ul>\n<li><strong>C\u00f3digos 4xx erosionan el \u00edndice con el tiempo.<\/strong> Una p\u00e1gina que devuelve 404 en varios intentos de rastreo se elimina. Si eliminas una p\u00e1gina, redir\u00edgela con 301 en lugar de dejar que d\u00e9 404.<\/li>\n<li><strong>C\u00f3digos 5xx ralentizan el rastreo y da\u00f1an rankings.<\/strong> Googlebot interpreta 5xx persistentes como &#8220;este sitio est\u00e1 enfermo.&#8221; La tasa de rastreo baja, la indexaci\u00f3n se enlentece, el ranking puede caer.<\/li>\n<li><strong>301 vs 302 importa.<\/strong> El 301 pasa equidad de enlace. El 302 se trata como temporal y puede que no lo haga. Si el movimiento es permanente, elige 301.<\/li>\n<\/ul>\n<p>La conclusi\u00f3n pr\u00e1ctica: los errores 5xx no son solo un problema de disponibilidad. Son un problema SEO que se agrava cuanto m\u00e1s persisten. Los <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/website-monitoring-errors-dns-tcp-tls-http\/\">errores DNS, TCP, TLS y HTTP<\/a> tienen cada uno un costo SEO diferente\u2014saber qu\u00e9 capa falla te ayuda a hacer triaje m\u00e1s 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=\"Diagrama de flujo para triaje de alertas de c\u00f3digos de estado HTTP\u2014qu\u00e9 capa revisar primero, cu\u00e1ndo notificar a on-call, cu\u00e1ndo revertir un despliegue\" 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\">Un camino simple de triaje desde el c\u00f3digo de estado hasta el primer paso de investigaci\u00f3n.<\/figcaption><\/figure>\n<h2 id='monitorear-c\u00f3digos-de-estado-http-sin-ahogarse-en-alertas'  id=\"boomdevs_35\">Monitorear c\u00f3digos de estado HTTP sin ahogarse en alertas<\/h2>\n<p>Cada equipo que monitorea tr\u00e1fico HTTP eventualmente enfrenta el mismo problema: demasiadas alertas, poca se\u00f1al. Algunas pr\u00e1cticas mantienen \u00fatil el monitoreo de c\u00f3digos de estado en lugar de ruidoso.<\/p>\n<p><strong>Alerta sobre tasas, no solicitudes individuales.<\/strong> Un 500 es ruido. Cincuenta 500 en cinco minutos es un incidente. Configura umbrales seg\u00fan tu volumen base de tr\u00e1fico.<\/p>\n<p><strong>Separa endpoints p\u00fablicos de los internos.<\/strong> Un 500 en API de checkout debe notificar. Un 500 en endpoint admin que nadie usa puede esperar a horas h\u00e1biles.<\/p>\n<p><strong>Prueba desde donde est\u00e1n tus usuarios.<\/strong> Una verificaci\u00f3n desde un solo centro de datos no detectar\u00e1 una falla regional de CDN. Usa una red de monitoreo con m\u00faltiples geograf\u00edas para detectar problemas localizados antes que los clientes.<\/p>\n<p><strong>Combina chequeos de estado con chequeos de contenido.<\/strong> 200 OK es un punto de partida, no una l\u00ednea de meta. Valida que la respuesta contenga lo que debe.<\/p>\n<p>El <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/supervision-de-aplicaciones-web\/\">monitoreo de aplicaciones web<\/a> de Dotcom-Monitor maneja los cuatro: alertas basadas en tasa, segmentaci\u00f3n de endpoints, ubicaciones globales de monitoreo y chequeos de contenido con navegador real. Para stacks con APIs intensivas, la <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/web-api-monitoring\/\">ruta de monitoreo API<\/a> a\u00f1ade validaci\u00f3n de esquema y SLOs de tiempo de respuesta encima del chequeo de c\u00f3digos de estado. Ambos alimentan el mismo <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/funciones-alertas\/\">canal de alertas<\/a> para que no est\u00e9s uniendo se\u00f1ales de tres proveedores distintos.<\/p>\n<h2 id='reflexiones-finales'  id=\"boomdevs_36\">Reflexiones finales<\/h2>\n<p>Los c\u00f3digos de estado HTTP m\u00e1s comunes no han cambiado en a\u00f1os. 200, 301, 404, 500, 502, 503\u2014ver\u00e1s todos esta semana. Lo que cambia es qu\u00e9 tan r\u00e1pido tu equipo pasa de &#8220;vi el c\u00f3digo&#8221; a &#8220;arregl\u00e9 la causa.&#8221;<\/p>\n<p>Esa brecha es donde un buen monitoreo paga dividendos. Los c\u00f3digos de estado solos te dicen que algo pas\u00f3. Los chequeos en capas\u2014estado, contenido, navegador real, multi-regi\u00f3n\u2014te dicen qu\u00e9, d\u00f3nde y qu\u00e9 hacer despu\u00e9s.<\/p>\n<p>Si quieres ver c\u00f3mo funciona, <a href=\"https:\/\/www.dotcom-monitor.com\/\">Dotcom-Monitor<\/a> tiene una prueba gratuita. Ap\u00fantalo a uno de tus endpoints y mira qu\u00e9 detecta.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Una referencia pr\u00e1ctica para ingenieros que reciben notificaciones cuando aparecen estos c\u00f3digos.<\/p>\n","protected":false},"author":21,"featured_media":33976,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-12264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=12264"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/33976"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=12264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=12264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=12264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}