El uptime es el porcentaje de tiempo que una web está en marcha y responde bien a quien la visita. Se calcula restando el tiempo caído del tiempo total y dividiendo por el total: un 99,9 % de uptime en un mes de 30 días deja 43 minutos de caída. Para mejorarlo primero hay que medirlo desde fuera, cada minuto, y luego atacar lo que de verdad tumba las webs pequeñas: certificados y dominios caducados, actualizaciones a ciegas y un hosting que va justo.
Qué es el uptime
La palabra viene del inglés (up, arriba, y time, tiempo) y en castellano también se dice disponibilidad. Su contrario es el downtime, el tiempo caído.
Ojo con una confusión que sale mucho en los foros. En Linux existe un comando que se llama igual:
$ uptime
10:42:17 up 41 days, 3:05, 1 user, load average: 0,31, 0,28, 0,25Eso te dice cuánto lleva encendido el servidor sin reiniciarse. Nada más. Un servidor puede llevar 41 días encendido y tu web dar un error 500 desde esta mañana. Cuando hablamos del uptime de una web hablamos de lo segundo: si alguien que entra desde fuera ve la página o no.
Cómo se calcula el uptime
La fórmula no tiene misterio:
uptime (%) = (tiempo total - tiempo caído) / tiempo total × 100Un ejemplo. Un mes de 30 días tiene 43.200 minutos. Si tu web ha estado caída 25 minutos en total, repartidos en tres cortes:
(43.200 - 25) / 43.200 × 100 = 99,94 %Parece un número buenísimo, ¿verdad? Pues son 25 minutos en los que nadie pudo comprar, reservar ni rellenar el formulario de contacto. Por eso conviene mirar siempre el porcentaje junto con los minutos.
Tabla de nueves: cuánto tiempo caído permite cada porcentaje
En el oficio se habla de «nueves»: tres nueves es 99,9 %, cuatro nueves 99,99 %. Esta es la cuenta para un día, un mes de 30 días y un año de 365:
| Uptime | Caída máxima al día | Al mes (30 días) | Al año |
|---|---|---|---|
| 99 % | 14 min 24 s | 7 h 12 min | 3 días 15 h 36 min |
| 99,5 % | 7 min 12 s | 3 h 36 min | 1 día 19 h 48 min |
| 99,9 % | 1 min 26 s | 43 min 12 s | 8 h 45 min |
| 99,95 % | 43 s | 21 min 36 s | 4 h 22 min |
| 99,99 % | 9 s | 4 min 19 s | 52 min 34 s |
| 99,999 % | menos de 1 s | 26 s | 5 min 15 s |
Para una web de empresa o una tienda pequeña, el 99,9 % es una meta razonable. Pasar de ahí ya pide dinero de verdad: servidores duplicados, balanceo, gente de guardia. El 99,999 % es cosa de bancos y operadoras, no hay para tanto en una web de una clínica dental.
El uptime que promete el hosting y el que tienes de verdad
Casi todos los hostings anuncian un 99,9 % o más en su acuerdo de servicio (el SLA). Ese número y el uptime de tu web acostumbran a ser cosas distintas, por varios motivos:
- Lo miden ellos y lo miden sobre su máquina. Si el servidor responde pero tu WordPress da «Error al establecer una conexión con la base de datos», para el hosting el servidor estaba arriba.
- El mantenimiento programado no suele contar. Lee la letra pequeña: las paradas avisadas con antelación normalmente quedan fuera del cálculo.
- La compensación es pequeña. Si incumplen, lo normal es que te devuelvan unos días de servicio en forma de crédito, y casi siempre lo tienes que reclamar tú.
- Los fallos «tuyos» no cuentan. Certificado caducado, dominio sin renovar, un plugin que rompe la portada: para el SLA, nada de eso es una caída.
La única forma de saber tu uptime real es medirlo tú, desde fuera de tu hosting, como lo vería un cliente. Si estás eligiendo proveedor, en la guía para elegir hosting explicamos cómo aprovechar el periodo de prueba para medirlo antes de quedarte.
Cómo medir el uptime bien
Un monitor de uptime pide tu página cada cierto tiempo y apunta si responde y cómo. Parece sencillo, pero según cómo lo montes el porcentaje sale bonito y falso. Lo que marca la diferencia:
- Frecuencia. Con una comprobación cada 5 minutos, un corte de 4 puede no verse nunca. Cada minuto es lo que pide una web con ventas o reservas.
- Desde fuera. Un script dentro del propio servidor no se entera si cae la red del centro de datos, y tampoco si el DNS deja de apuntar a tu IP.
- Confirmar antes de contar. Una sola petición fallida puede ser un tropiezo de la red entre el monitor y tu web. Si otra comprobación desde otro punto del mundo también falla, la caída es real.
- Comprobar el contenido, no solo el código. Una página en blanco puede devolver un
200 OK. Pedir que aparezca un texto concreto (el nombre de la empresa, el pie de página) caza esos casos. - Vigilar las páginas que importan. La portada puede ir bien y el formulario de reservas no. Si una página hace caja, merece su propio monitor.
- Guardar el historial. Sin historial no hay porcentaje mensual, ni forma de ver si una caída de martes a las 3:00 se repite cada semana (muchas veces resulta ser la copia de seguridad).
Puedes hacer una prueba a mano en un pispás con curl, que te da el código y el tiempo total:
$ curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://tudominio.com/
200 0.412sPara el día a día, un monitor de uptime hace eso mismo cada minuto, sin que tú estés por ello.
Qué tumba el uptime de una web pequeña
Las caídas espectaculares de los grandes salen en la prensa. Las de una web pequeña son mucho más de andar por casa, y casi todas se podían ver venir:
| Causa | Cómo se ve | Qué hacer |
|---|---|---|
| Certificado SSL caducado | «La conexión no es privada» (NET::ERR_CERT_DATE_INVALID) | Vigilar la fecha y la renovación automática. Ver la guía del certificado SSL. |
| Dominio sin renovar | Página de aparcamiento del registrador o DNS_PROBE_FINISHED_NXDOMAIN | Renovación automática con una tarjeta que no caduque y aviso con semanas de margen. |
| Actualización de un plugin o del tema | «Ha habido un error crítico en esta web» o error 500 | Copia antes de actualizar, probar en una copia de pruebas y no actualizar el viernes por la tarde. |
| Hosting al límite | 508 Resource Limit Is Reached, 503 o la web lentísima en horas punta | Caché, mirar el consumo en el panel y subir de plan si toca. |
| Tareas programadas pesadas | Caídas a la misma hora cada día o cada semana | Mover la copia o el cron a la madrugada y mirar que no bloqueen la base de datos. |
| Disco lleno | Errores al guardar, sesiones que fallan, base de datos que no arranca | Borrar logs y copias viejas, rotar logs. |
| Cambios de DNS | La web «desaparece» para unos sí y para otros no | Bajar el TTL unos días antes del cambio y comprobar con dig. |
| Picos de robots o ataques | Tiempo de respuesta disparado, 503 o 429 | Limitar los robots abusivos y poner un cortafuegos delante. |
| Un tercero del que dependes | Errores de la CDN (Cloudflare da 5xx propios) aunque tu servidor vaya bien | Saber de quién dependes y tener plan B. |
Lo del tercero no es teoría. El 18 de noviembre de 2025 Cloudflare estuvo devolviendo errores 5xx en una parte grande de las webs que pasan por su red, de las 11:20 a las 17:06 UTC, por un fallo interno de configuración. Lo explican ellos mismos en su informe del incidente. Mogollón de servidores estaban perfectamente y sus webs, caídas igual.
Cómo mejorar el uptime, paso a paso
En orden de lo que más rinde con menos esfuerzo:
- Empieza a medir hoy. Sin datos no sabes si tienes un 99,95 % o un 98 %. Un mes de mediciones ya te dice mucho.
- Quita de en medio lo que caduca. Certificado y dominio con aviso propio, aunque el hosting diga que «se renueva solo». La renovación automática a veces falla sin decir nada.
- Actualiza con red. Copia de seguridad antes, una web de pruebas si la tienes, y alguien pendiente de la web en la hora siguiente. Las copias automáticas son tu botón de deshacer.
- Quítale trabajo al servidor. Una caché de página bien puesta hace que un pico de visitas no llegue a PHP ni a la base de datos. En WordPress, mira la comparativa de plugins de caché.
- Mira el tiempo de respuesta. Una web que pasa de 300 ms a 3 segundos acostumbra a estar avisando de que se va a caer. El TTFB es el primer síntoma.
- Revisa el hosting con los datos en la mano. Si las caídas se repiten y el soporte va a la suya, los números del monitor te sirven para reclamar o para cambiar.
- Redundancia, solo si compensa. Un DNS con varios servidores, una CDN, un segundo servidor que entra si cae el primero. Para una tienda que factura cada hora puede valer la pena; para una web de empresa de cinco páginas, normalmente no.
- Ten un plan para cuando caiga. Tarde o temprano pasa. Tener escrito qué mirar primero te ahorra media hora de nervios: lo tienes en qué hacer cuando tu web se cae.
El uptime y Google
Una caída de unos minutos no te hunde en Google. Lo que sí está documentado es cómo reacciona su rastreador: según la documentación de Google Search Central, los errores 5xx y 429 hacen que Googlebot baje el ritmo de rastreo, y si una URL sigue dando error de servidor de forma persistente, acaba saliendo del índice. Las caídas cortas y aisladas se recuperan solas. Las que duran días o se repiten cada semana, no tanto.
Cómo mide el uptime WatcherWolf
Te lo contamos sin rodeos, por si te va bien para tus webs:
- Comprueba cada web cada minuto en todos los planes (puedes espaciarlo si quieres) desde servidores en la Unión Europea, en París.
- Desde el plan Studio, antes de avisarte, sondas en seis continentes confirman la caída. Si ellas ven la web bien, no hay aviso: era un tropiezo de red.
- Puedes pedir que aparezca un texto concreto en la respuesta, para cazar páginas en blanco que devuelven 200.
- Te avisa al caer y al volver, con lo que ha durado, por correo, Telegram, notificaciones de la app, Slack, Teams, Discord o Google Chat. Cómo montar esos avisos lo tienes en la guía de alertas de monitoreo web.
- Además vigila el certificado SSL y la caducidad del dominio, que son dos de las causas de caída más tontas y más frecuentes.
- El historial se guarda siempre; a la vista tienes de 3 meses (Solo) a 2 años (Business).
Mide tu uptime real: 14 días gratis, sin tarjeta
Si llevas webs de clientes, en monitoreo web para agencias y freelancers verás cómo organizarlas por grupos y mandarles el informe.
Preguntas frecuentes
¿Qué uptime es aceptable para una web?
Para una web de empresa o una tienda pequeña, un 99,9 % mensual es una buena meta: unos 43 minutos caídos al mes como mucho. Por debajo del 99,5 % (más de 3 horas y media al mes) ya vale la pena buscar la causa.
¿Uptime y disponibilidad son lo mismo?
En la práctica sí: uptime es el término en inglés y disponibilidad el castellano. Algunos contratos calculan la disponibilidad sin contar las paradas de mantenimiento avisadas, así que mira cómo la define cada uno.
¿Cada cuánto hay que comprobar el uptime de una web?
Cada minuto si la web vende, reserva o recibe contactos. Con comprobaciones cada 5 o 10 minutos se escapan los cortes cortos y el porcentaje sale mejor de lo que es.
¿Cómo calculo el uptime de mi web si no tengo monitor?
Sin mediciones desde fuera solo puedes estimarlo con los logs del servidor o el panel del hosting, y no verás los fallos de DNS, de certificado o de red. Lo fiable es poner un monitor y esperar un mes de datos.
¿El mantenimiento programado cuenta como tiempo caído?
Para tus visitas, sí: la web no está. En los SLA de los hostings normalmente no cuenta si lo avisan antes. Si mides tú, puedes apuntarlo aparte, pero no lo escondas.
