Qué es uptime y por qué importa
· 5 min de lectura
El uptime es el porcentaje de tiempo que la web está disponible. 99% son más de tres días de caída al año; meta realista 99,9% y enterarse en un minuto.
Definición: qué medimos exactamente
El uptime es la relación entre el tiempo en que el servicio responde como se espera (típicamente HTTP 200, contenido con palabra clave) y el tiempo total de medición. Se expresa en porcentaje, normalmente para periodos de 30 o 365 días.
Lo contrario es el downtime - el tiempo en que el servicio no responde, devuelve 5xx o tarda más del timeout configurado. Incluye también el mantenimiento programado, salvo que lo excluyas explícitamente del cálculo (lo que deberías comunicar en el SLA).
Tabla de "nueves": cuánto tiempo significa cada decimal
| Uptime | Downtime permitido / año | Mes | Día |
|---|---|---|---|
| 99 % | 3 días 15 h | 7 h 18 min | 14 min |
| 99,5 % | 1 día 19 h | 3 h 39 min | 7 min |
| 99,9 % (three nines) | 8 h 45 min | 43 min | 1 min 26 s |
| 99,95 % | 4 h 22 min | 21 min | 43 s |
| 99,99 % (four nines) | 52 min | 4 min 22 s | 8,6 s |
| 99,999 % (five nines) | 5 min 15 s | 26 s | 0,86 s |
Cada nueve adicional multiplica los costes de infraestructura. Five nines (99,999 %) es el terreno de los proveedores globales con redundancia activa intercontinental - para la mayoría de aplicaciones de negocio, 99,9 % es el objetivo correcto.
Qué uptime necesitas realmente
- Web de marketing (empresa, portafolio): 99 % es suficiente. Un visitante que llega durante una caída lo intentará luego.
- App SaaS con cliente desktop: 99,9 % es el mínimo. Los clientes pagan por un trabajo que no pueden hacer durante el downtime.
- E-commerce, pasarela de pago, servicio en tiempo real: 99,95 % o más. Cada minuto = pérdidas directas.
- Infraestructura (API usada por otros): Al menos 99,99 %. Tu SLA limita el SLA de tus clientes.
Cómo se mide el uptime
El servicio de monitorización llama periódicamente a tu endpoint (típicamente HTTP GET, pero también socket TCP, ping ICMP o resolución DNS). Cada comprobación tiene un resultado binario: up o down.
Un intervalo común son 1-5 minutos. Cuanto más corto, antes detectas una caída, pero más alertas falsas recibes (un glitch local de red, un breve reinicio por deploy). La solución es la comprobación multi-región: una caída se confirma solo cuando la reportan N regiones, no una sola.
Fuentes más comunes de "nueves perdidos"
- Certificado SSL/TLS caducado. El navegador bloquea la página. Sin monitorización lo sabrás el lunes por la mañana cuando suene el teléfono.
- Caducidad del dominio. Todo el DNS deja de funcionar. Email, web y status page - todo cae a la vez.
- Worker de base de datos caído. La web devuelve 500 o entra en timeout para parte de las requests. Un ping clásico quizá hasta pase, aunque la aplicación esté rota.
- DDoS o flooding. El servidor se satura, el tiempo de respuesta sube por encima del límite y la monitorización reporta una caída.
- Deploy mal hecho. Una nueva versión tiene un bug que rompe alguna ruta. Sin tests de integración te enteras cuando los clientes empiezan a quejarse.
Conclusión
El uptime no es un número de marketing - es la medida de cuánto puedes confiar en tu propia infraestructura. 99,9 % de uptime no es un lujo, es un requisito estándar para cualquier servicio que genere ingresos o tenga clientes que pagan.
El paso uno es medir. Si no tienes monitorización externa, técnicamente no sabes qué uptime tienes - solo lo estimas.
Empieza a medir el uptime de tus servicios
ePulz.io rastrea tus endpoints en intervalos desde 1 minuto desde varias regiones. 7 días gratis.
Prueba ePulz.io gratis - 7 días sin tarjeta de crédito.
Crear cuenta