Detector de caídas de servicios

¿Cómo comprobar una caída con nuestro Down Detector?

Empieza por el servicio que utilizas y consulta los datos que encajan con tu problema. No hace falta leer todos los gráficos para decidir qué probar después.

1. Elige un servicio o un sitio web

   Usa el estado del servicio para una aplicación compatible o la comprobación web para una dirección pública. Una opción muestra lo que comunica el proveedor; la otra comprueba si responde una página concreta.

2. Identifica la función afectada

   Lee primero los incidentes activos. Abre Componentes para revisar el inicio de sesión, las subidas o una API. La última actualización puede precisar a quién afecta el problema.

3. Guarda la información útil

   Actualiza los datos antes de decidir. Copia o descarga un informe con fecha para soporte. Comparte el enlace cuando otra persona necesite una comprobación nueva, no un resultado guardado.

Un buen punto de partida cuando algo deja de funcionar

Pequeños ajustes para sacar más partido a la consulta

Elige el tipo de consulta antes de buscar. Guarda hasta cinco servicios como favoritos en este navegador, filtra por categoría o muestra solo los problemas notificados. La actualización automática consulta las fuentes oficiales mientras la página está visible; la comprobación de un sitio se realiza una sola vez. El filtro de componentes te ayuda a localizar una función o región. Copia el informe para conservar la fecha y hora de la observación, o comparte un enlace para abrir una vista nueva. Los archivos PNG, texto y JSON incluyen las pruebas disponibles, no una predicción de cuándo se recuperará el servicio.

¿Por qué una web puede funcionar mientras su aplicación está caída?

Un servicio es más que su página principal.

La primera página que abres puede funcionar de forma independiente de las cuentas, la búsqueda, la mensajería, los archivos o los pagos. Por eso existen las caídas parciales: la página pública carga, pero la acción que necesitas no se completa. Una comprobación web satisfactoria y un componente afectado pueden ser resultados correctos al mismo tiempo.

Nuestro Down Detector separa esas perspectivas. El estado del servicio refleja la información publicada por el proveedor; la comprobación web examina una dirección pública en un momento registrado. Ninguna comprueba tu cuenta privada, un pago autenticado ni todas las regiones. Si los resultados parecen contradictorios, consulta la descripción del incidente para identificar la función afectada, en lugar de confiar únicamente en una etiqueta.

La guía de Google sobre supervisión de sistemas distribuidos explica la diferencia entre síntomas y causas, y por qué una observación externa y una medición interna pueden mostrar partes distintas de un problema.

¿Qué significan investigación, supervisión y resolución de un incidente?

Las actualizaciones cuentan una evolución, no solo muestran un color.

En investigación suele indicar que el proveedor está evaluando el problema. Identificado significa que ha acotado su causa. En supervisión indica que se ha aplicado un cambio y se observa su efecto; no garantiza que todos los usuarios se hayan recuperado. Resuelto es el cierre del incidente por parte del proveedor. Un análisis posterior puede explicar qué ocurrió y qué medidas se tomarán.

Los avisos pueden llegar después de los primeros fallos y las sesiones pueden recuperarse en momentos diferentes. Mostramos la última actualización disponible y los componentes afectados cuando se especifican, separando los incidentes activos del historial. El mantenimiento programado aparece aparte porque no equivale a una caída inesperada. Si un incidente no está asociado a un producto, señalamos esa incertidumbre sin declarar que todo el producto está caído.

Puedes contrastar los datos con el registro del proveedor; por ejemplo, la documentación pública de estado de Cloudflare distingue incidentes, estados de componentes y mantenimiento programado.

¿Una comprobación fallida significa que toda la web está caída?

Lee la respuesta antes de elegir una solución.

No necesariamente. Una respuesta 404 puede indicar que una página ha cambiado de ubicación, aunque el resto de la web funcione. Una respuesta 403 puede deberse a restricciones de acceso o protección contra solicitudes automatizadas. Un error del servidor, una respuesta DNS ausente o un tiempo de espera agotado aportan más indicios sobre esa solicitud, pero no demuestran una caída mundial ni su causa.

Si falla una sola dirección, prueba la página principal. Si fallan varias webs sin relación en tu dispositivo, revisa la conexión y compara otra red. Si la página principal funciona pero una acción no, consulta los componentes y el mensaje de error exacto. Guarda hora, acción y resultado para soporte, sin compartir contraseñas, cookies de sesión ni enlaces privados. Actualizar sin parar suele aportar menos información que comprobar de nuevo tras un aviso del proveedor.

Para interpretar un código de respuesta, la referencia de estados HTTP de MDN distingue respuestas correctas, errores de acceso y errores del servidor.

Cómo leer el historial sin confundirlo con la disponibilidad

Ejemplo ilustrativo, no datos actuales de un servicio

Supongamos que un proveedor publica ocho incidentes en un mes. Siete son breves y están resueltos; uno empezó hace cinco días y sigue activo. Una lista limitada a los más recientes podría ocultarlo, por eso nuestra lista de incidentes activos lo mantiene visible sin importar su antigüedad. El gráfico cuenta registros según su fecha de inicio, no personas afectadas, horas de interrupción ni avisos de usuarios. Ocho registros no permiten calcular si la disponibilidad fue del 99 % o del 99,9 %: se necesitan un servicio definido, un periodo de observación y tiempo de indisponibilidad medido. Un día vacío solo significa que no se encontró el inicio de un incidente en los datos disponibles.

¿Qué significa cada estado del servicio?

Operativo

La fuente del proveedor indica que el servicio está operativo. Aun así, una cuenta, función o región concreta puede tener problemas.

Si sigue fallando, prueba otra red y otro dispositivo antes de cambiar la configuración.

Rendimiento reducido

El proveedor informa de un rendimiento reducido, como solicitudes más lentas o errores intermitentes.

Consulta el componente afectado y las notas del incidente. Evita enviar repetidamente pagos u otras solicitudes importantes.

Interrupción parcial

Parte del servicio se encuentra indisponible según el proveedor; otros componentes pueden seguir funcionando.

Comprueba si el componente afectado corresponde a la función que necesitas y sigue las actualizaciones del proveedor.

Interrupción grave

La fuente informa de una interrupción importante en el servicio o los componentes que cubrimos, no necesariamente en todos los productos de la empresa.

Usa una alternativa si la tarea es urgente. Consulta el incidente oficial para seguir la recuperación.

Mantenimiento

El proveedor ha marcado un componente o servicio como en mantenimiento.

Lee el aviso para conocer el alcance y el horario. La hora de finalización prevista no garantiza la recuperación.

Incidencia notificada

Hay un incidente activo, pero la fuente disponible puede no indicar toda su gravedad.

Abre el incidente oficial para ver las funciones afectadas y las recomendaciones del proveedor.

No hay incidencias activas registradas

La fuente de incidentes conectada no muestra incidentes activos. Esto no equivale a haber probado correctamente todas las funciones.

Compara el resultado con la función que falla. Es posible que un problema nuevo todavía no se haya reconocido.

Estado no disponible

No hemos podido verificar la fuente, o no ofrece información suficiente para clasificar el estado.

Abre la página oficial de estado e intenta actualizar más tarde. La falta de datos no significa que el servicio esté caído ni que funcione.

¿Sigues teniendo problemas? Empieza por tu síntoma

Antes de contactar con soporte, anota la hora, la función afectada, la red y el error exacto. Comparte un enlace público de estado o un informe descargado, nunca contraseñas ni enlaces privados de tu cuenta.

Cómo interpretar los gráficos de estado

Los componentes no son personas

La barra cuenta los componentes que devuelve el proveedor, como API o regiones. No mide clientes afectados, tráfico ni tiempo de disponibilidad. Puede haber muchos componentes operativos y un problema precisamente en el que utilizas.

El inicio de un incidente no es su duración

Cuando hay historial disponible, el gráfico agrupa los incidentes recibidos por fecha de inicio durante los últimos 30 días UTC. Un incidente de varios días no cuenta como uno nuevo cada día. Un cero o la falta de historial no demuestra un servicio ininterrumpido.

El directorio es una instantánea de las fuentes

La vista general cuenta señales de servicios, no avisos de visitantes. Productos relacionados pueden compartir un mismo incidente; no los sumes como caídas independientes. Las fuentes desconocidas se mantienen separadas de los servicios sin problemas registrados.

¿Qué tan recientes son estos resultados?

La consulta y la actualización del proveedor tienen fechas distintas

La fecha de consulta indica cuándo ClockTools recibió una respuesta válida de la fuente. La actualización del proveedor es la fecha que facilita esa fuente, cuando está disponible. No es necesariamente el inicio ni la resolución del incidente. Una fecha antigua por sí sola no demuestra una caída.

Actualizar comprueba de nuevo, pero no omite todas las cachés

Las fuentes oficiales se actualizan aproximadamente cada dos minutos mientras la página está visible y la actualización automática está activada. Las respuestas válidas de estado pueden reutilizarse durante dos minutos, y las de historial separado durante cinco. Actualizar puede mostrar las mismas fechas. La comprobación de una web es puntual, no una supervisión continua.

Los avisos pueden llegar después del problema

El proveedor puede publicar un incidente después de que lo detecten los usuarios. Si no podemos verificar una fuente, mostramos datos no disponibles en lugar de indicar que todo funciona. Compara tus síntomas, la ubicación de la comprobación y la fuente oficial antes de valorar el alcance del problema.

Qué cubre nuestro directorio de estados

Consultamos fuentes públicas de servicios de IA, aplicaciones de colaboración, plataformas de juegos e infraestructura en la nube. Google Workspace y Google Cloud publican incidencias, no una garantía de que cada cuenta funciona. Una incidencia de Codex no afecta automáticamente a ChatGPT. Los filtros de componentes separan sus resultados, y los datos sin correspondencia o no disponibles se identifican con claridad.

Tus comprobaciones y tu privacidad

Las consultas oficiales no necesitan tu cuenta ni una clave API. Las direcciones web se envían a nuestro servidor para la prueba externa; solo se admiten direcciones HTTP y HTTPS públicas. Utiliza enlaces públicos normales, nunca paneles privados ni URL con secretos. Esta herramienta no guarda tu historial de búsqueda. Las respuestas públicas se almacenan brevemente en caché para reducir las solicitudes repetidas.

Historial sin disponibilidad inventada

La lista de incidencias solo contiene registros devueltos por la fuente oficial. La retención varía, y algunas interfaces conectadas no ofrecen historial. No convertimos la ausencia de incidencias en una afirmación de disponibilidad del 100 %, ni inventamos avisos de visitantes o estimaciones de afectados. Esta página es independiente de Downdetector y de los servicios incluidos.

Consultar Verizon, Spectrum, Virgin Media y Facebook

Una caída de Internet suele ser local. Elige Verizon, Spectrum o Virgin Media para abrir la consulta del proveedor por zona o cuenta. En Facebook, compara la comprobación del sitio con la función que falla en tu dispositivo. Roblox tiene una fuente oficial de estado; Steam ofrece una señal más limitada de su API pública. Estas fuentes no miden las interrupciones del mismo modo.