Alternativas self-hosted a Opsgenie antes de abril 2027

Atlassian adquirió Opsgenie en 2018 y lo integró progresivamente en la suite Jira. El anuncio de fin de vida se publicó en la página de estado oficial de Atlassian: el servicio se detiene el 5 de abril de 2027. Los usuarios disponen de algo más de un año para migrar sus políticas de guardia, sus integraciones y su historial de incidencias. Grafana OnCall OSS, el componente open source de Grafana OnCall, fue archivado en GitHub el 24 de marzo de 2026. El equipo de Grafana Labs indicó que la versión cloud sigue disponible, pero el repositorio de autoalojamiento ya no recibe parches ni nuevas funcionalidades. La convergencia de estos dos eventos en menos de doce meses crea una ventana de migración que los equipos harían bien en planificar ahora en lugar de esperar la presión de las últimas semanas antes del plazo de abril de 2027.

OneUptime utiliza una arquitectura multicontenedor orquestada por Docker Compose. Para un equipo de menos de veinte personas con un volumen de alertas moderado (menos de mil eventos al día), un VPS con 4 vCPU y 8 GB de RAM es una base sólida. Por debajo de 4 GB de RAM varios contenedores compiten al arranque y provocan reinicios repetidos. El almacenamiento debe estar en un volumen SSD: OneUptime escribe frecuentemente en PostgreSQL y en su bus de eventos interno. Prever al menos 40 GB para los logs y la base de datos en un periodo de seis meses. El servidor debe exponer los puertos 80 y 443; se puede colocar un proxy inverso nginx o Caddy delante si el VPS ya aloja otros servicios. Se requieren Docker Engine versión 24 o superior y Docker Compose versión 2.20 o superior. Una dirección IP fija y un nombre de dominio con registro DNS A son necesarios para el certificado TLS y para que los webhooks entrantes sean accesibles.

OneUptime expone un endpoint webhook entrante para cada monitor o integración creada. En la interfaz, ve a *Integrations → Incoming Webhooks* y crea una nueva integración de tipo Prometheus Alertmanager. La interfaz genera una URL con la forma https://tu-dominio/api/v1/incoming-request/<uuid>. En la configuración de Alertmanager de Prometheus, añade un receptor de tipo webhook apuntando a esa URL. El campo send_resolved: true permite a OneUptime cerrar automáticamente una incidencia cuando Alertmanager envía la notificación de resolución. Para integración desde Grafana, usa el tipo de contacto *Webhook* e introduce la misma URL. OneUptime analiza el JSON entrante y extrae automáticamente el título, la severidad y las etiquetas de la alerta de Prometheus. Si envías alertas desde una herramienta personalizada, el formato esperado está documentado en la página de integración: un campo title y un campo description son suficientes para crear una incidencia.

Los planificadores de guardia (On-Call Schedules) en OneUptime definen quién está disponible, a qué hora y para qué servicio. Un planning se asocia a una o varias capas: cada capa representa una rotación de equipo. La rotación puede ser diaria, semanal o sobre un periodo personalizado. Cada miembro del equipo puede establecer sus preferencias de notificación en su perfil: correo inmediato, SMS tras dos minutos, llamada de voz si la incidencia no es reconocida tras cinco minutos. Los escalados se configuran en las Alert Policies: si la persona de guardia en el nivel 1 no responde en la ventana configurada, la alerta sube automáticamente al nivel 2, que puede ser otra persona, un equipo diferente o un canal Slack compartido. Esta cadena de escalado es visible en el historial de cada incidencia, lo que facilita las revisiones post-mortem.

El problema más frecuente en el primer arranque es un contenedor PostgreSQL que no responde antes de que el contenedor de aplicación intente conectarse. OneUptime incluye directivas healthcheck en su docker-compose.yml oficial; si usas una versión modificada, asegúrate de que el servicio app tiene una entrada depends_on con condición service_healthy sobre el servicio postgres. Un segundo problema común afecta a las variables SMTP: si los correos de verificación de cuenta no se envían, verifica que SMTP_PORT sea 587 (STARTTLS) y no 465 (SSL directo) si tu proveedor SMTP lo requiere. Para diagnosticar errores silenciosos, observa los logs del worker en tiempo real con docker compose logs -f oneuptime-worker. Por último, si el puerto 443 ya está ocupado por otro servicio, OneUptime arrancará pero no será accesible: modifica el mapeo de puerto en docker-compose.yml o detén el servicio que compite antes de lanzar la pila.

Opsgenie permite exportar políticas de alerta, planificadores de guardia e historial de incidencias en formato JSON o CSV desde *Settings → Export*. Estas exportaciones contienen reglas de enrutamiento, miembros de equipo e integraciones activas. La importación en OneUptime no es automática: hay que recrear las políticas manualmente o mediante la API REST de OneUptime usando los datos exportados. Empezar por las integraciones críticas (Prometheus, Grafana, Datadog) y avanzar luego hacia los planificadores de guardia y finalmente las notificaciones secundarias es el enfoque recomendado. Planifica un periodo de funcionamiento en paralelo de al menos dos semanas: ambos sistemas reciben las mismas alertas mientras los equipos validan las nuevas políticas. La fecha límite del 5 de abril de 2027 deja tiempo suficiente para una migración cuidadosa si se inicia antes de enero de 2027. Esperar hasta las últimas semanas expone a los equipos a un corte forzado sin posibilidad de vuelta atrás si falta alguna integración.