Aller plus loin

Surveiller son serveur et recevoir des alertes utiles

Mis à jour le 4 octobre 2026 · 10 min de lecture

Une bonne surveillance vous prévient avant que quelqu’un vous dise « le site ne marche plus ». Une mauvaise surveillance vous envoie cent notifications par jour… et vous finissez par les ignorer, y compris le jour où c’est grave.

Ce guide met en place la première, avec une règle simple : une alerte doit toujours demander une action.

La règle d’or : alerter sur les changements, pas sur les états

Une alerte qui dit « tout va bien » toutes les cinq minutes ne sert à rien. Ce qui compte :

• une alerte quand ça tombe ;
• une alerte quand ça revient ;
• et rien entre les deux.

Ajoutez une tolérance : un service qui ne répond pas pendant 30 secondes à 4 h du matin (pendant une mise à jour, par exemple) ne mérite pas de vous réveiller. Trois échecs d’affilée, si.

Quoi surveiller

Quoi	Pourquoi	Comment
Chaque site et application	C’est ce que voient vos utilisateurs	Une requête HTTPS, avec un mot attendu dans la page
Les certificats HTTPS	Un certificat expiré bloque tout le monde	Alerte 14 jours avant l’expiration
L’espace disque	Un disque plein casse les bases de données	Alerte au-delà de 85 %
Les conteneurs	Un conteneur arrêté ou en boucle de redémarrage	docker ps ou leur état de santé
Les sauvegardes	Une sauvegarde qui échoue en silence est le pire scénario	Vérifier l’âge de la dernière sauvegarde
Le serveur lui-même	Redémarrage inattendu, panne de l’hébergeur	Une sonde extérieure

Uptime Kuma : le tableau de bord

Uptime Kuma est l’outil le plus simple pour démarrer : une interface claire, des dizaines de types de sondes et de canaux de notification. Installez-le avec le générateur docker-compose ou depuis sa fiche application.

Pour chaque site, créez une sonde HTTP(s) - Mot-clé plutôt qu’une simple sonde HTTP :

• URL : https://cloud.mondomaine.fr/status.php (ou la page d’accueil de l’appli) ;
• Mot-clé : un mot qui n’apparaît que si l’appli fonctionne vraiment (par exemple installed pour Nextcloud) ;
• Intervalle : 60 secondes ;
• Nouvelles tentatives : 3, pour la tolérance ;
• Expiration du certificat : cochez la notification, avec 14 jours d’avance.

Pourquoi un mot-clé ? Parce qu’une page de maintenance ou une page d’erreur de l’application peut très bien répondre avec un code 200 (« tout va bien »). Le mot-clé prouve que l’application elle-même fonctionne.

Recevoir les alertes sur son téléphone

Uptime Kuma sait envoyer vers presque tout. Les trois options les plus simples :

• Discord : créez un salon privé, puis Paramètres du salon → Intégrations → Webhooks, et collez l’URL dans Uptime Kuma. Pratique si vous utilisez déjà Discord.
• Telegram : créez un bot avec @BotFather, récupérez le jeton et votre identifiant de discussion.
• ntfy : une appli de notifications open source, que vous pouvez même auto-héberger.

Le piège : surveiller un serveur depuis lui-même

Si Uptime Kuma tourne sur le serveur qu’il surveille, il tombe avec lui : aucune alerte ne part le jour où tout le serveur s’arrête. Deux solutions :

1. Une seconde machine surveille la première : un Raspberry Pi à la maison surveille le VPS, et le VPS surveille le Raspberry Pi. Chacun prévient si l’autre disparaît.
2. Un service de surveillance externe gratuit pour une ou deux sondes de base (la page d’accueil, par exemple). Il suffit à détecter qu’un serveur entier ne répond plus.

Un watchdog maison pour le reste

Uptime Kuma voit les sites de l’extérieur. Certaines choses ne se voient que de l’intérieur : l’espace disque, l’âge des sauvegardes, un conteneur arrêté. Un petit script lancé toutes les 15 minutes s’en charge.

Voici le principe, avec une alerte Discord seulement quand l’état change :

#!/bin/bash
# /opt/scripts/watchdog.sh : alerte Discord quand un problème apparaît ou disparaît
WEBHOOK="https://discord.com/api/webhooks/..."   # à garder secret (chmod 700 sur le script)
STATE=/var/lib/watchdog; mkdir -p "$STATE"

alert() { # alert <id> <ok|ko> <message>
  local old; old=$(cat "$STATE/$1" 2>/dev/null || echo ok)
  [ "$old" = "$2" ] && return                      # pas de changement : pas de message
  echo "$2" > "$STATE/$1"
  local icon; [ "$2" = ko ] && icon="🔴" || icon="🟢"
  curl -fsS -m 10 -H "Content-Type: application/json" \
    -d "{\"content\": \"$icon $3\"}" "$WEBHOOK" > /dev/null
}

# Espace disque
used=$(df --output=pcent / | tail -1 | tr -dc 0-9)
if [ "$used" -ge 85 ]; then alert disque ko "Disque rempli à $used %"
else alert disque ok "Espace disque revenu à $used %"; fi

# Conteneurs arrêtés alors qu'ils devraient tourner
down=$(docker ps -a --filter "status=exited" --filter "label=com.docker.compose.project" --format '{{.Names}}' | tr '\n' ' ')
if [ -n "$down" ]; then alert conteneurs ko "Conteneurs arrêtés : $down"
else alert conteneurs ok "Tous les conteneurs tournent"; fi

# Âge de la dernière sauvegarde : au moins un fichier de moins de 26 h
recent=$(find /opt/backups -type f -mmin -1560 | head -1)
if [ -z "$recent" ]; then alert sauvegarde ko "Aucune sauvegarde depuis plus de 26 h"
else alert sauvegarde ok "Les sauvegardes ont repris"; fi

Puis lancez-le toutes les 15 minutes :

sudo chmod 700 /opt/scripts/watchdog.sh
echo "*/15 * * * * root /opt/scripts/watchdog.sh" | sudo tee /etc/cron.d/watchdog

Adaptez les seuils et ajoutez vos propres vérifications : chaque bloc tient en deux lignes.

Lire les journaux quand une alerte tombe

Une alerte dit que quelque chose ne va pas. Les journaux disent pourquoi :

docker compose logs --tail 100 app        # les derniers messages d'une application
docker ps -a                              # quels conteneurs tournent, depuis quand
journalctl -u docker --since "1 hour ago" # les messages de Docker lui-même
df -h && free -h                          # disque et mémoire

Gardez en tête la méthode des couches du guide complet : DNS, serveur, pare-feu, reverse proxy, application, données. Remontez-les dans l’ordre.

Récapitulatif

• Une sonde avec mot-clé par application, 3 tentatives avant l’alerte
• Alerte sur l’expiration des certificats, 14 jours avant
• Notifications sur le téléphone, dans un canal réservé aux alertes
• Une surveillance depuis une autre machine
• Un watchdog pour le disque, les conteneurs et les sauvegardes, qui ne parle que lorsque l’état change