Alternatives self-hosted à Opsgenie avant avril 2027

Opsgenie a été racheté par Atlassian en 2018 et intégré progressivement dans la suite Jira. L'annonce de fin de vie a été publiée sur la page d'état officielle Atlassian : le service s'arrête le 5 avril 2027. Les utilisateurs disposent d'un peu plus d'un an pour migrer leurs politiques d'astreinte, leurs intégrations et leurs historiques d'incidents. Grafana OnCall OSS, le composant open source de Grafana OnCall, a quant à lui été archivé sur GitHub le 24 mars 2026. L'équipe Grafana Labs a indiqué que la version cloud reste disponible, mais le dépôt en auto-hébergement ne reçoit plus de correctifs ni de nouvelles fonctionnalités. Les équipes qui avaient basé leur infrastructure de gestion d'incidents sur cette brique se retrouvent dans une situation identique : elles doivent migrer avant que les failles de sécurité non corrigées ne deviennent un risque réel. La convergence de ces deux événements en moins de douze mois crée une fenêtre de migration que les équipes ont intérêt à planifier dès maintenant plutôt que d'attendre la pression des dernières semaines avant l'échéance d'avril 2027.

OneUptime utilise une architecture multi-conteneurs orchestrée par Docker Compose. Pour une équipe de moins de vingt personnes avec un volume d'alertes modéré (moins de mille événements par jour), un VPS avec 4 vCPU et 8 Go de RAM constitue une base correcte. En dessous de 4 Go de RAM, plusieurs conteneurs entrent en concurrence au démarrage et provoquent des redémarrages intempestifs. Le stockage doit être sur un volume SSD : OneUptime écrit fréquemment dans PostgreSQL et dans son bus d'événements interne. Prévoir au minimum 40 Go pour les logs et la base de données sur une durée de six mois. Le serveur doit exposer les ports 80 et 443 ; un reverse proxy nginx ou Caddy peut être placé devant si le VPS héberge déjà d'autres services. Docker Engine version 24 ou supérieure et Docker Compose version 2.20 ou supérieure sont requis. Une adresse IP fixe et un nom de domaine avec enregistrement DNS A sont nécessaires pour le certificat TLS et pour que les webhooks entrants soient joignables.

OneUptime expose un endpoint webhook entrant pour chaque moniteur ou intégration créée. Dans l'interface, allez dans *Integrations → Incoming Webhooks* et créez une nouvelle intégration de type Prometheus Alertmanager. L'interface génère une URL de la forme https://votre-domaine/api/v1/incoming-request/<uuid>. Dans la configuration Alertmanager de Prometheus, ajoutez un receiver de type webhook pointant vers cette URL. Le champ send_resolved: true permet à OneUptime de fermer automatiquement un incident quand Alertmanager envoie la notification de résolution. Pour une intégration depuis Grafana, utilisez le type de contact *Webhook* et renseignez la même URL. OneUptime analyse le JSON entrant et extrait automatiquement le titre, la sévérité et les labels de l'alerte Prometheus. Si vous envoyez des alertes depuis un outil personnalisé, le format attendu est documenté dans la page d'intégration : un champ title et un champ description suffisent pour créer un incident.

Les plannings d'astreinte dans OneUptime (On-Call Schedules) définissent qui est disponible, à quelle heure et pour quel service. Un planning est associé à une ou plusieurs couches (layers) : chaque couche représente une rotation d'équipe. La rotation peut être quotidienne, hebdomadaire ou sur une période personnalisée. Chaque membre d'équipe peut renseigner ses préférences de notification dans son profil : e-mail immédiat, SMS après deux minutes d'attente, appel vocal si l'incident n'est pas acquitté après cinq minutes. Les escalades se configurent dans les politiques d'alerte (Alert Policies) : si la personne d'astreinte au niveau 1 ne répond pas dans le délai configuré, l'alerte remonte automatiquement au niveau 2, qui peut être une autre personne, une équipe différente ou un canal Slack partagé. Cette chaîne d'escalade est visible dans l'historique de chaque incident, ce qui facilite les revues post-mortem.

Le problème le plus fréquent au premier démarrage est un conteneur PostgreSQL qui ne répond pas avant que le conteneur applicatif ne tente de s'y connecter. OneUptime intègre des healthcheck dans son docker-compose.yml officiel ; si vous utilisez une version modifiée, assurez-vous que le service app a bien une directive depends_on avec condition service_healthy sur le service postgres. Un second problème courant concerne les variables SMTP : si les e-mails de vérification de compte ne partent pas, vérifiez que SMTP_PORT est bien 587 (STARTTLS) et non 465 (SSL direct) si votre fournisseur SMTP l'exige. Pour diagnostiquer les erreurs silencieuses, consultez les logs du worker en temps réel avec docker compose logs -f oneuptime-worker. Enfin, si le port 443 est déjà occupé par un autre service, OneUptime démarrera mais sera inaccessible : modifiez le mapping de port dans le docker-compose.yml ou arrêtez le service concurrent avant de lancer la stack.

Opsgenie permet d'exporter les politiques d'alerte, les plannings d'astreinte et l'historique des incidents au format JSON ou CSV depuis *Settings → Export*. Ces exports contiennent les règles de routage, les membres d'équipe et les intégrations actives. L'import dans OneUptime n'est pas automatique : il faut recréer les politiques manuellement ou via l'API REST de OneUptime en s'appuyant sur les données exportées. Commencer par les intégrations critiques (Prometheus, Grafana, Datadog) puis progresser vers les plannings d'astreinte et enfin les notifications secondaires est l'approche recommandée. Prévoyez une période de double-fonctionnement d'au moins deux semaines : les deux systèmes reçoivent les mêmes alertes pendant que les équipes valident les nouvelles politiques. L'échéance du 5 avril 2027 laisse suffisamment de temps pour une migration soignée si elle est démarrée avant janvier 2027. Attendre les dernières semaines expose les équipes à un basculement contraint, sans possibilité de revenir en arrière si une intégration manque.