Todo desarrollador eventualmente se encuentra con la palabra uptime en una pagina de estado, un plan de hosting o un acuerdo de nivel de servicio. Suena simple, pero los detalles importan. La diferencia entre 99.9% y 99.99% de uptime no es academica — se traduce directamente en minutos de inactividad que tus usuarios experimentaran y dinero que tu negocio podria perder.
Esta guia cubre todo lo que necesitas saber sobre uptime: que significa, como calcularlo, que representan los "nines", como se relaciona con SLAs y SLOs, y como el monitoreo de uptime te ayuda a anticiparte a las caidas.
Que es Uptime?
Uptime es la cantidad de tiempo que un sistema, servidor o servicio esta operativo y accesible. Tipicamente se expresa como un porcentaje del tiempo total transcurrido. Si un servidor web funciono sin interrupcion durante un mes entero, su uptime seria 100%. Si se cayo durante una hora en ese mes, su uptime bajaria a aproximadamente 99.86%.
El concepto aplica a cualquier sistema que se espera este disponible: sitios web, APIs, bases de datos, servidores DNS, pasarelas de pago y microservicios internos. Cuando alguien dice "nuestra API tiene 99.9% de uptime," significa que durante un periodo de medicion dado, la API estuvo accesible y respondiendo correctamente el 99.9% del tiempo.
Uptime es el inverso del tiempo de inactividad. Si el uptime es 99.95%, el tiempo de inactividad es 0.05% del periodo total.
La formula de uptime
Uptime % = ((Tiempo Total - Tiempo de Inactividad) / Tiempo Total) x 100Para un mes de 30 dias (720 horas), si tu servicio experimento 45 minutos de inactividad:
Uptime % = ((43,200 - 45) / 43,200) x 100 = 99.896%Eso te pone justo debajo del umbral de "tres nueves." Para entender por que eso importa, veamos los nines en detalle.
Los "Nines" Explicados: de 99% a 99.999%
Cuando los ingenieros hablan de uptime, frecuentemente usan el atajo de los "nines." Tres nueves significa 99.9%. Cuatro nueves significa 99.99%. Cada nueve adicional reduce el tiempo de inactividad permitido por un factor de diez, lo que hace cada paso significativamente mas dificil de lograr.
| Uptime % | Nombre Comun | Inactividad por Ano | Inactividad por Mes | Inactividad por Semana |
|---|---|---|---|---|
| 99% | Dos nueves | 3 dias, 15 horas | 7 horas, 18 minutos | 1 hora, 41 minutos |
| 99.5% | Dos y medio nueves | 1 dia, 19 horas | 3 horas, 39 minutos | 50 minutos |
| 99.9% | Tres nueves | 8 horas, 46 minutos | 43.8 minutos | 10.1 minutos |
| 99.95% | Tres y medio nueves | 4 horas, 23 minutos | 21.9 minutos | 5 minutos |
| 99.99% | Cuatro nueves | 52.6 minutos | 4.4 minutos | 1 minuto |
| 99.999% | Cinco nueves | 5.26 minutos | 26.3 segundos | 6 segundos |
La mayoria de las empresas SaaS apuntan a tres nueves (99.9%) como un balance realista entre confiabilidad y costo de ingenieria. Los proveedores de nube como AWS y Google Cloud tipicamente ofrecen SLAs de 99.95% o 99.99% para sus servicios principales de computo y bases de datos. Lograr cinco nueves requiere infraestructura redundante en multiples regiones, failover automatizado y un proceso maduro de respuesta a incidentes.
Para contexto, 99% de uptime suena alto pero permite mas de tres dias y medio de inactividad al ano. Para una API de comercio electronico, eso podria significar miles de transacciones fallidas. La diferencia entre 99% y 99.9% no es una pequena optimizacion — es un compromiso de ingenieria fundamentalmente diferente.
Como se Calcula el Uptime?
En la practica, el uptime se mide mediante sistemas de monitoreo que envian solicitudes a intervalos regulares y registran si cada verificacion tiene exito o falla. El calculo entonces se convierte en:
Uptime % = (Verificaciones Exitosas / Verificaciones Totales) x 100Aqui hay una funcion practica en JavaScript que calcula el uptime a partir de un conjunto de resultados de monitoreo:
/**
* Calcular porcentaje de uptime a partir de resultados de verificacion.
* @param {Array} checks - Array de objetos { timestamp, status }
* @returns {Object} Estadisticas de uptime
*/
function calculateUptime(checks) {
const total = checks.length;
if (total === 0) return { uptimePercent: 0, totalChecks: 0, failures: 0 };
const failures = checks.filter(c => c.status >= 400 || c.status === 0).length;
const successful = total - failures;
const uptimePercent = (successful / total) * 100;
// Calcular ventanas de inactividad
const checkInterval = 60; // segundos entre verificaciones
const downtimeSeconds = failures * checkInterval;
const downtimeMinutes = (downtimeSeconds / 60).toFixed(1);
return {
uptimePercent: uptimePercent.toFixed(4),
totalChecks: total,
successful,
failures,
downtimeMinutes,
nines: uptimePercent >= 99.999 ? 5
: uptimePercent >= 99.99 ? 4
: uptimePercent >= 99.9 ? 3
: uptimePercent >= 99 ? 2
: 1
};
}
// Ejemplo de uso
const results = calculateUptime(checksUltimos30Dias);
console.log(`Uptime: ${results.uptimePercent}% (${results.nines} nueves)`);
console.log(`Inactividad: ${results.downtimeMinutes} minutos`);Si quieres verificar rapidamente donde se encuentra tu servicio, prueba nuestra calculadora de uptime — ingresa tus horas totales y tiempo de inactividad para obtener tu porcentaje de uptime y nivel de nueves al instante.
Consideraciones de medicion
Los calculos de uptime son tan buenos como el monitoreo detras de ellos. Los factores clave incluyen:
- Frecuencia de verificacion: Un monitor que verifica cada 5 minutos podria perderse completamente una caida de 3 minutos. Intervalos de un minuto son el minimo para APIs en produccion.
- Ubicaciones de verificacion: Un servicio podria ser accesible desde Virginia pero estar caido en Frankfurt. El monitoreo multi-region previene puntos ciegos.
- Que cuenta como "caido": Algunas organizaciones cuentan errores HTTP 5xx como tiempo de inactividad. Otras requieren una falla completa de conexion. Tu SLA deberia definir esto explicitamente.
- Mantenimiento planificado: Muchos SLAs excluyen ventanas de mantenimiento programado de los calculos de inactividad. Esto vale la pena escrutar al evaluar las afirmaciones de uptime de un proveedor.
Que es el Monitoreo de Uptime?
El monitoreo de uptime es la practica de verificar continuamente si un sitio web, API o servicio esta accesible y respondiendo correctamente. Un sistema de monitoreo envia solicitudes HTTP automatizadas — u otras sondas especificas de protocolo — a intervalos regulares y te alerta cuando algo falla.
Hay tres enfoques principales para el monitoreo de uptime, y la mayoria de los equipos usa una combinacion:
1. Monitoreo sintetico
Sistemas externos envian solicitudes a tus endpoints desde multiples ubicaciones geograficas en un horario fijo. Esta es la forma mas comun de monitoreo de uptime. Te dice si tu servicio es accesible desde el mundo exterior, que es lo que importa a tus usuarios.
Los monitores sinteticos tipicamente miden tiempo de respuesta, codigos de estado, validez del certificado TLS y tiempo de resolucion DNS. Herramientas como Nurbak Watch, UptimeRobot y Better Stack caen en esta categoria.
2. Monitoreo de usuarios reales (RUM)
JavaScript embebido en tu frontend recopila datos de rendimiento de sesiones reales de usuarios. RUM captura latencia del mundo real, errores y tiempos de carga de pagina en diferentes dispositivos, navegadores y condiciones de red. No reemplaza el monitoreo sintetico — lo complementa mostrando como los usuarios reales experimentan tu servicio.
3. Health checks internos
Tu aplicacion expone un endpoint de health check (tipicamente /health o /healthz) que reporta el estado de dependencias internas: conexiones de base de datos, capas de cache, APIs de terceros y sistemas de colas. Los health checks internos te ayudan a distinguir entre "el servidor esta funcionando" y "el servidor esta funcionando correctamente."
Una configuracion de monitoreo robusta combina los tres: verificaciones sinteticas capturan caidas visibles externamente, RUM revela problemas de experiencia de usuario y health checks exponen fallas de dependencias internas antes de que se propaguen.
Uptime vs. Disponibilidad vs. Confiabilidad
Estos tres terminos se usan frecuentemente de manera intercambiable, pero miden cosas diferentes. Entender la distincion te ayuda a establecer los objetivos correctos y comunicarte claramente con las partes interesadas.
| Concepto | Definicion | Mide | Ejemplo |
|---|---|---|---|
| Uptime | Tiempo que el sistema esta funcionando y accesible | Esta respondiendo el servidor? | El servidor retorno HTTP 200 en el 99.9% de las verificaciones |
| Disponibilidad | Tiempo que el sistema funciona correctamente para los usuarios | Pueden los usuarios completar sus tareas? | La API respondio pero con 30 segundos de latencia — tecnicamente "activa" pero efectivamente no disponible |
| Confiabilidad | Consistencia del comportamiento correcto a lo largo del tiempo | Con que frecuencia falla el sistema? | El servicio se cae una vez por trimestre vs. una vez por semana — mismo porcentaje de uptime, diferente confiabilidad |
Un servidor puede tener 100% de uptime pero pobre disponibilidad si responde con errores o latencia extrema. De manera similar, dos servicios pueden tener 99.9% de uptime, pero uno podria experimentar una sola caida de 8 horas mientras el otro tiene cientos de breves interrupciones. El primero es posiblemente mas confiable porque su modo de falla es predecible, aunque los numeros sean identicos.
Al definir tu estrategia de monitoreo, rastrea los tres. Uptime te dice que el servidor esta encendido. Disponibilidad te dice que es util. Confiabilidad te dice si puedes confiar en el.
Terminos Comunes de SLA Explicados: SLA, SLO, SLI y Error Budget
Si trabajas con servicios en la nube, proveedores de pago o cualquier dependencia externa, te encontraras con estos terminos. Forman una jerarquia que conecta promesas de negocio con metricas de ingenieria.
SLA — Acuerdo de Nivel de Servicio
Un SLA es un contrato entre un proveedor de servicios y un cliente. Define que nivel de servicio puede esperar el cliente y que sucede si el proveedor no cumple. Los SLAs tipicamente especifican porcentajes de uptime, umbrales de tiempo de respuesta y remedios (generalmente creditos de servicio) por violaciones.
Ejemplo: "Garantizamos 99.95% de uptime mensual. Si el uptime cae por debajo de este umbral, los clientes afectados reciben un 10% de credito de servicio."
SLO — Objetivo de Nivel de Servicio
Un SLO es un objetivo interno que generalmente es mas estricto que el SLA. Si tu SLA promete 99.9%, tu SLO podria ser 99.95%. Este margen le da a tu equipo espacio para detectar y corregir problemas antes de que se conviertan en violaciones de SLA. Los SLOs son metas de ingenieria, no promesas al cliente.
SLI — Indicador de Nivel de Servicio
Un SLI es la metrica real que mides. Es el punto de datos que te dice si estas cumpliendo tu SLO. Los SLIs comunes incluyen latencia de solicitudes (p50, p95, p99), tasa de errores y porcentaje de uptime. Tu sistema de monitoreo produce SLIs. Tu SLO define el rango aceptable. Tu SLA define las consecuencias de exceder ese rango.
Error budget
Un error budget es la cantidad de falta de confiabilidad permitida derivada de tu SLO. Si tu SLO es 99.9% de uptime, tu error budget es 0.1% — aproximadamente 43 minutos al mes. Cuando tu error budget se agota, el equipo deberia congelar los despliegues de funcionalidades y enfocarse en trabajo de confiabilidad. Este concepto, popularizado por las practicas de SRE de Google, previene que los equipos optimicen por velocidad a costa de la estabilidad.
| Termino | Tipo | Quien lo establece | Ejemplo |
|---|---|---|---|
| SLA | Contrato / promesa | Negocio + legal | 99.9% de uptime o el cliente recibe creditos |
| SLO | Objetivo interno | Equipo de ingenieria | 99.95% de uptime — mas estricto que el SLA |
| SLI | Metrica medida | Sistema de monitoreo | 99.97% de solicitudes retornaron HTTP 2xx en menos de 500ms |
| Error budget | Falla permitida | Derivado del SLO | 0.05% = 21.9 minutos de inactividad al mes |
Como Mejorar el Uptime
Mejorar el uptime no se trata de encontrar una solucion magica. Requiere defensas en capas a traves de infraestructura, codigo de aplicacion, practicas de despliegue y respuesta a incidentes. Aqui estan las estrategias que mas importan.
1. Redundancia y failover
Los puntos unicos de falla son la causa mas comun de inactividad. Eliminalos ejecutando multiples instancias de servicios criticos detras de un balanceador de carga. Usa despliegues multi-region o multi-zona de disponibilidad para que una falla de hardware o particion de red en una ubicacion no derribe todo tu servicio.
Para bases de datos, usa replicas de lectura y failover automatizado. Para DNS, usa multiples proveedores. Para CDNs, asegura que tu origen pueda servir trafico directamente si el CDN falla.
2. Monitoreo continuo de uptime
No puedes mejorar lo que no mides. Configura monitoreo sintetico que verifique tus endpoints cada minuto desde multiples regiones. Configura alertas que notifiquen a tu equipo en segundos cuando ocurra una falla — via Slack, PagerDuty, email o SMS.
Rastrea no solo el estado binario activo/inactivo sino tambien tendencias de tiempo de respuesta. Un aumento gradual en latencia es frecuentemente la primera senal de una caida inminente. Cuando tu API se cae, el costo se mide en ingresos perdidos, integraciones rotas y confianza erosionada del usuario.
3. Degradacion elegante
Disena tu aplicacion para seguir funcionando — incluso con capacidad reducida — cuando una dependencia falla. Si tu motor de recomendaciones esta caido, muestra articulos populares en lugar de retornar un error. Si un proveedor de pagos externo esta lento, encola la transaccion y reintenta. Los circuit breakers, timeouts y respuestas de fallback mantienen la experiencia del usuario intacta durante fallas parciales.
4. Seguridad en despliegues
Los despliegues fallidos causan un porcentaje significativo de caidas. Mitiga esto con despliegues canary (despliega al 5% del trafico primero), despliegues blue-green (mantiene una version anterior lista para servir) y rollbacks automatizados disparados por picos en tasa de errores. Nunca despliegues un viernes sin un plan de rollback automatizado.
5. Respuesta a incidentes
El tiempo de inactividad es inevitable. Lo que separa a los equipos de alto uptime del resto es que tan rapido detectan, responden y resuelven incidentes. Documenta tus runbooks. Define rotaciones de guardia. Practica la respuesta a incidentes regularmente. Despues de cada incidente, conduce un post-mortem sin culpas e implementa las correcciones que prevengan recurrencia.
El tiempo medio de recuperacion (MTTR) es frecuentemente mas importante que el tiempo medio entre fallas (MTBF). Un equipo que se recupera de incidentes en 5 minutos tendra mejor uptime que un equipo que tarda 2 horas, incluso si el segundo equipo tiene menos incidentes en total.
6. Pruebas de carga y planificacion de capacidad
Muchas caidas suceden porque el trafico excede lo que la infraestructura puede manejar. Ejecuta pruebas de carga regularmente — no solo antes del lanzamiento, sino a medida que tus patrones de trafico evolucionan. Configura auto-scaling con umbrales apropiados. Monitorea la utilizacion de recursos (CPU, memoria, conexiones de base de datos) y configura alertas antes de alcanzar los limites.
Preguntas Frecuentes
Que significa 99.9% de uptime?
99.9% de uptime — frecuentemente llamado tres nueves — significa que un servicio puede estar no disponible por un maximo de 8 horas, 45 minutos y 36 segundos al ano, o aproximadamente 43.8 minutos al mes. Cada nueve adicional reduce el tiempo de inactividad permitido por un factor de diez. Por ejemplo, 99.99% (cuatro nueves) permite solo 52.6 minutos de inactividad al ano.
Como se calcula el porcentaje de uptime?
El porcentaje de uptime se calcula usando la formula: Uptime % = ((Tiempo Total - Tiempo de Inactividad) / Tiempo Total) x 100. Por ejemplo, si tu servicio experimento 2 horas de inactividad en un mes de 30 dias (720 horas), tu uptime seria ((720 - 2) / 720) x 100 = 99.72%. Puedes usar nuestra calculadora de uptime para computar esto al instante.
Cual es la diferencia entre uptime y disponibilidad?
Uptime mide si un servidor o servicio esta funcionando y accesible. Disponibilidad es un concepto mas amplio que considera si el servicio esta funcionando correctamente desde la perspectiva del usuario final, incluyendo rendimiento degradado. Un servidor puede tener 100% de uptime pero disponibilidad reducida si responde con errores o latencia extrema.
Que es el monitoreo de uptime y por que lo necesito?
El monitoreo de uptime es la practica de verificar continuamente si un sitio web, API o servicio esta accesible y respondiendo correctamente. Tipicamente involucra enviar solicitudes HTTP automatizadas a intervalos regulares desde una o mas ubicaciones geograficas. Necesitas monitoreo de uptime para detectar caidas antes que tus usuarios, cumplir compromisos de SLA y recopilar datos para respuesta a incidentes y post-mortems. Herramientas como Nurbak Watch automatizan este proceso con verificaciones multi-region y alertas instantaneas.