Alertes téléphoniques Uptime Kuma : faire sonner votre mobile

Table des matières

• Pourquoi Uptime Kuma ne peut pas vous appeler tout seul
• Ce qu'il vous faut
• Étape 1 — Créer un canal qui vous appelle
• Étape 2 — Ajouter Echobell comme notification webhook
• Étape 3 — Envoyer une charge utile que vous pourrez filtrer
• Étape 4 — Empêcher les rétablissements de vous appeler
• Étape 5 — Régler le moniteur pour qu'il ne crie pas au loup
• Ne sonner qu'en dehors des heures de bureau
• Partager l'alerte avec votre équipe
• Ce que ce montage ne vous apporte pas
• Dépannage
• Questions fréquentes
• Uptime Kuma peut-il passer un appel nativement ?
• Cela fonctionne-t-il avec un Uptime Kuma auto-hébergé derrière un pare-feu ?
• L'appel contourne-t-il le mode Ne pas déranger ?
• Comment éviter d'être appelé lors du rétablissement ?
• Plusieurs personnes peuvent-elles être appelées pour le même moniteur ?
• Pour conclure
• Articles connexes

Uptime Kuma prend en charge plus de 90 fournisseurs de notifications, mais aucun ne fait sonner votre téléphone. Pour recevoir un appel quand un moniteur tombe, envoyez la notification Webhook d'Uptime Kuma vers un canal Echobell dont le type de notification est Appel. Ce guide donne le corps personnalisé exact à utiliser, la façon de séparer les alertes de panne des alertes de rétablissement, et les deux erreurs qui cassent silencieusement l'ensemble.

Uptime Kuma est l'outil de supervision de disponibilité auto-hébergé le plus répandu — environ 90 000 étoiles sur GitHub, la version 2.5.0 étant sortie en août 2026. Il surveille des points de terminaison HTTP, des ports TCP, des enregistrements DNS, des conteneurs Docker et bien d'autres choses, et il détecte réellement très bien les pannes.

Là où il vous laisse exposé, c'est sur le dernier kilomètre : faire parvenir l'alerte à un humain qui dort.

Pourquoi Uptime Kuma ne peut pas vous appeler tout seul

La liste des notifications d'Uptime Kuma est longue — Telegram, Discord, Slack, e-mail, Gotify, ntfy et des dizaines d'autres — mais toutes délivrent un message. Les messages sont soumis au bouton silencieux de votre téléphone, au mode Ne pas déranger et aux modes de concentration iOS. À 3 h du matin, cela signifie que l'alerte arrive et qu'il ne se passe rien.

Il n'existe pas de fournisseur natif « appelle-moi ». Les options vers lesquelles on se tourne habituellement sont :

• Twilio — vous pouvez construire des appels vocaux par-dessus, mais le fournisseur Twilio d'Uptime Kuma envoie des SMS. Passer à la voix suppose d'écrire un service intermédiaire, d'acheter un numéro et de payer à l'appel.
• PagerDuty, Zenduty, Spike.sh, Splunk On-Call — ceux-là passent bien des appels, mais ce sont des plateformes complètes de gestion d'incidents, avec une tarification par utilisateur à l'avenant. Le bon choix s'il vous faut des rotations et des politiques d'escalade ; excessif si vous voulez simplement faire sonner un téléphone.
• Passerelles SMS — un SMS reste un message, et sous iOS un texte ne perce pas le mode de concentration si l'expéditeur n'est pas dans votre liste d'exceptions.

Une demande de notifications par appel VoIP est ouverte depuis un moment sur le dépôt d'Uptime Kuma. En attendant, le fournisseur générique Webhook est la porte de sortie : il peut envoyer n'importe quoi vers n'importe quelle URL, et c'est tout ce dont vous avez besoin.

Ce qu'il vous faut

• Une instance Uptime Kuma en service (ce guide vise la 2.x ; le corps personnalisé fonctionne aussi à partir de la 1.23)
• Echobell installé (App Store / Google Play)
• Cinq minutes

Votre instance Uptime Kuma a besoin d'un accès HTTPS sortant vers hook.echobell.one. Elle n'a pas besoin d'être joignable depuis Internet — il s'agit d'un webhook sortant, donc un moniteur qui tourne sur un serveur domestique ou dans un réseau privé convient parfaitement.

Étape 1 — Créer un canal qui vous appelle

Dans Echobell, créez un canal nommé par exemple Production Down. Réglez le type de notification de l'abonnement sur Appel. C'est ce réglage qui compte : les alertes de type Appel arrivent sous forme d'appel entrant et sonnent malgré les modes de concentration iOS et Ne pas déranger, ce qu'une notification push ne fait pas.

Définissez les modèles ainsi :

Titre : 🔴 {{monitor}} est hors service
Corps : {{message}}
Cible : {{target}}

Copiez ensuite l'URL de webhook du canal. Elle ressemble à ceci :

https://hook.echobell.one/t/<channel-token>

Traitez cette URL comme un secret : quiconque la détient peut faire sonner votre téléphone.

Étape 2 — Ajouter Echobell comme notification webhook

Dans Uptime Kuma, allez dans Settings → Notifications → Setup Notification et renseignez :

Laissez Additional Headers vide.

Étape 3 — Envoyer une charge utile que vous pourrez filtrer

C'est l'étape que la plupart des guides passent sous silence, et c'est elle qui fait la différence entre un système d'alerte et une machine à bruit.

Collez ceci dans Custom Body :

{
  "monitor": "{{name}}",
  "target": "{{hostnameOrURL}}",
  "message": "{{ msg | strip_newlines }}",
  "up": "{{ heartbeatJSON['status'] }}"
}

Uptime Kuma rend les corps personnalisés avec Liquid et expose ces variables :

Deux détails de cette charge utile sont délibérés :

strip_newlines sur msg. Le message d'Uptime Kuma contient souvent des sauts de ligne, et un saut de ligne brut dans une chaîne JSON produit du JSON invalide. Sans ce filtre, votre webhook échoue par intermittence — uniquement pour les erreurs dont le texte se trouve contenir un retour à la ligne. Si votre version d'Uptime Kuma dispose du filtre Liquid json, alors "message": {{ msg | json }} (attention : sans guillemets autour) est encore plus sûr, car il échappe aussi les guillemets.

heartbeatJSON['status'] plutôt que {{status}}. La variable status rend un texte avec émoji, peu commode à comparer. Le statut du heartbeat, lui, est un simple nombre :

• 0 — hors service
• 1 — en service
• 2 — en attente
• 3 — maintenance

Les guillemets ("up": "{{ ... }}") comptent également, et l'étape 5 explique pourquoi.

Étape 4 — Empêcher les rétablissements de vous appeler

Une même notification Uptime Kuma se déclenche à la panne et au rétablissement. Tel quel, ce montage vous appelle quand le service tombe, puis vous rappelle quand il se répare tout seul. C'est ce second appel qui apprend aux gens à ignorer le premier.

Séparez-les grâce aux conditions Echobell, évaluées avant toute distribution :

Sur le canal Production Down (type de notification Appel), définissez la condition :

up == "0"

Créez un second canal nommé Production Recovered, réglez son type de notification sur Normal et donnez-lui la condition :

up == "1"

Avec ces modèles :

Titre : ✅ {{monitor}} est de nouveau en service
Corps : {{message}}

Ajoutez ensuite une seconde notification webhook dans Uptime Kuma — même corps personnalisé, mêmes moniteurs, mais pointant vers l'URL du canal de rétablissement. Les deux notifications reçoivent tous les événements ; chaque canal écarte la moitié qui ne le concerne pas.

Résultat : les pannes sonnent, les rétablissements arrivent sous forme de push discret que vous lirez le matin.

Étape 5 — Régler le moniteur pour qu'il ne crie pas au loup

Un appel qui se révèle n'être qu'un hoquet réseau de deux secondes est pire que pas d'appel du tout, car le suivant sera écarté lui aussi. Trois réglages d'Uptime Kuma, sur le moniteur lui-même, font l'essentiel du travail :

• Retries — mettez 2 ou 3. Uptime Kuma ne marque le moniteur hors service qu'après ce nombre d'échecs consécutifs, ce qui filtre les paquets perdus isolés.
• Heartbeat Retry Interval — la fréquence de revérification pendant l'échec. 20 à 30 secondes constituent un bon équilibre ; combiné à 3 tentatives, vous détectez une vraie panne en une minute environ.
• Resend Notification if Down X times consecutively — réglé sur 10 par exemple, Uptime Kuma rappellera si le service est toujours hors service après dix vérifications de plus. C'est une politique d'escalade rudimentaire, mais elle fonctionne.

Si vous voulez qu'un appel manqué soit retenté immédiatement plutôt que d'attendre le renvoi, activez Réessayer les appels échoués dans les réglages de l'application Echobell.

Ne sonner qu'en dehors des heures de bureau

En journée, vous avez probablement déjà un tableau de bord sous les yeux, et un téléphone qui sonne n'est qu'une interruption superflue. Les variables de temps système d'Echobell (toutes en UTC) permettent à un même canal de se comporter différemment selon l'heure :

up == "0" && (hour >= 17 || hour < 9)

Cette condition ne vous appelle qu'en dehors de 09:00–17:00 UTC. Faites pointer un second canal, de type Normal, sur la condition inverse pour les push de journée :

up == "0" && hour >= 9 && hour < 17

Pensez à décaler selon votre fuseau : ces variables sont toujours calculées en UTC. Le sujet est traité plus en détail dans les notifications par fenêtre horaire avec des conditions UTC.

Partager l'alerte avec votre équipe

Un canal Echobell se partage avec vos collègues via un lien d'abonnement, et chaque abonné choisit son propre type de notification. Le même moniteur peut donc faire sonner le téléphone de la personne d'astreinte tout en arrivant comme un push normal pour les autres — sans tarification par siège ni règles de routage supplémentaires dans Uptime Kuma.

Cela s'accorde aussi avec la démarche de confidentialité qui vous a poussé à auto-héberger : vos moniteurs restent sur votre infrastructure, et Echobell conserve le contenu et l'historique des notifications sur l'appareil plutôt que sur ses serveurs.

Ce que ce montage ne vous apporte pas

Poser franchement la limite vous évitera une mauvaise migration plus tard. Echobell est une couche de distribution, pas une plateforme de gestion d'incidents. Il n'offre pas :

• de plannings d'astreinte ni de passations follow-the-sun
• d'arbres d'escalade qui alertent automatiquement une seconde personne
• de chronologies d'incident, de suivi des accusés de réception ni d'outils de post-mortem

Si votre équipe a besoin de tout cela, il vous faut PagerDuty, Grafana Cloud IRM ou équivalent. Ce montage couvre la lacune précise laissée ouverte par Uptime Kuma : convertir une panne détectée en un téléphone qui sonne vraiment. Pour un exploitant seul, une petite équipe ou un homelab, c'est généralement l'intégralité du besoin.

Dépannage

Le bouton Test ne fait rien. C'est le comportement attendu avec la charge utile ci-dessus, et cela déroute tout le monde la première fois. Au moment du test, Uptime Kuma n'a aucun heartbeat à rendre, donc {{ heartbeatJSON['status'] }} devient une chaîne vide et aucune condition ne correspond. Pour tester correctement, créez un moniteur TCP jetable visant un port sur lequel rien n'écoute (127.0.0.1:9) et laissez-le échouer.

Le webhook échoue par intermittence. Presque toujours le problème des sauts de ligne : vérifiez que msg passe bien par strip_newlines. Cela ne casse que pour les messages d'erreur contenant un retour à la ligne, d'où l'impression d'aléatoire.

Echobell renvoie success: false avec un HTTP 200. Le jeton du canal est erroné ou le canal a été supprimé. Echobell répond 200 pour un jeton inconnu mais de longueur valide : examinez donc le corps JSON, pas le code de statut.

HTTP 405. Le canal a l'option POST Only activée et quelque chose a envoyé un GET. Uptime Kuma envoie en POST, donc cela signifie généralement que vous avez ouvert l'URL dans un navigateur.

Rien ne sonne, mais la notification arrive. Le type de notification de l'abonnement est Normal ou Sensible au temps, pas Appel. Ce type se choisit par abonné : vérifiez-le sur l'appareil qui ne sonne pas.

Questions fréquentes

Uptime Kuma peut-il passer un appel nativement ?

Non. Uptime Kuma compte plus de 90 fournisseurs de notifications, mais tous délivrent des messages. Les appels nécessitent de router un webhook vers un service capable d'appeler, comme Echobell, ou d'utiliser une plateforme payante de gestion d'incidents.

Cela fonctionne-t-il avec un Uptime Kuma auto-hébergé derrière un pare-feu ?

Oui. Le webhook est une requête HTTPS sortante émise par votre instance Uptime Kuma : elle doit seulement pouvoir joindre hook.echobell.one. Votre instance n'a pas besoin d'adresse publique.

L'appel contourne-t-il le mode Ne pas déranger ?

Oui. Le type de notification Appel d'Echobell se présente comme un appel entrant, qui sonne malgré les modes de concentration iOS et Ne pas déranger. Voir contourner le mode Concentration iOS pour les alertes critiques pour les détails et les réglages concernés.

Comment éviter d'être appelé lors du rétablissement ?

Utilisez deux canaux avec conditions — up == "0" pour le canal d'appel et up == "1" pour un canal de rétablissement en priorité normale — et faites pointer une notification webhook sur chacun. L'étape 4 ci-dessus détaille la marche à suivre.

Plusieurs personnes peuvent-elles être appelées pour le même moniteur ?

Oui. Partagez le canal avec vos collègues ; chaque abonné choisit son propre type de notification. Toutes les personnes abonnées au canal d'appel seront appelées.

Pour conclure

Le montage tient en un webhook, un corps personnalisé et deux conditions. Il laisse vos moniteurs Uptime Kuma, votre logique de nouvelles tentatives et vos pages d'état exactement en l'état, et il comble l'écart entre « la supervision a remarqué » et « un humain a remarqué ».

Téléchargez Echobell pour iPhone ou récupérez-le sur Google Play, puis branchez d'abord un moniteur non critique et laissez-le échouer volontairement. Faites confiance au chemin avant d'en dépendre.

---

Articles connexes

• Documentation d'intégration Uptime Kuma
• Référence des conditions de canal
• Alertes Upptime avec Echobell
• Alertes téléphoniques lors de pannes d'API
• Guide du développeur pour vaincre la fatigue d'alerte