---
title: "Activer les notifications"
description: "Recevoir les alertes par e-mail, notification push, Telegram ou webhook — et ne recevoir que celles qui comptent."
lang: fr
canonical: "https://www.stathall.com/docs/activer-notifications/"
updated: "2026-09-23"
---

# Activer les notifications


Par défaut, une anomalie s'affiche dans la **boîte de réception** du
cockpit et nulle part ailleurs. Tout envoi sortant est un choix explicite.

## E-mail

**Paramètres → Notifications** : cochez ce que vous voulez recevoir. Les
e-mails partent à l'adresse de votre compte, vérifiée à l'inscription.

## Notification push

Ouvrez l'application mobile, connectez-vous, acceptez l'invite du système.
L'appareil apparaît ensuite dans **Paramètres → Notifications**, où vous
pouvez le retirer. Refuser l'invite n'empêche rien d'autre : l'application
fonctionne entièrement sans.

## Telegram

1. Créez un bot auprès de `@BotFather` et copiez son jeton.
2. Démarrez une conversation avec votre bot, puis récupérez l'identifiant
   de la discussion.
3. **Paramètres → Notifications → Ajouter un canal → Telegram**, collez les
   deux valeurs, puis envoyez un message de test — le canal n'est activé
   qu'après un test réussi.

## Webhook

Une URL en HTTPS, signée à l'envoi : chaque requête porte une signature que
vous vérifiez avec le secret partagé affiché à la création. Les adresses
internes et les plages privées sont refusées.

## Heures calmes

Une plage horaire pendant laquelle rien ne part, sauf les alertes de niveau
**P0** — celles qui n'attendent pas le matin. Les autres sont mises en file
et envoyées à la sortie de la plage.

## Pourquoi vous recevez peu d'alertes

C'est l'intention. Une alerte n'est envoyée que si elle est **actionnable** :
un pic d'une minute n'ouvre rien, un cœur saturé n'est pas une machine
saturée, une prévision incertaine se tait plutôt que de deviner. Une alerte
qui se trompe trois fois n'est plus lue à la quatrième.

## Une machine d'intégration continue

Un runner (GitLab, Jenkins…) sature son processeur **à chaque job** : c'est
son travail, pas un incident. Dans la configuration du serveur, onglet
**Alertes**, cochez **Runner CI** : les alertes processeur et charge par
défaut se taisent, et tout ce qui casse vraiment un runner reste surveillé —
disque qui se remplit (cache Docker), mémoire, swap, température, SMART,
service du runner, agent. Un seuil que vous posez à la main dans le tableau
reste appliqué, comme une règle écrite pour cette machine ou son groupe ; une
règle générale, définie pour tous les serveurs, ne défait pas le profil. Quand GitLab Runner tourne sur la machine, le cockpit vous
le propose ; il ne l'active jamais tout seul.

Les conteneurs **éphémères** qu'un job GitLab crée (nommés
`runner-…-project-…-concurrent-…`) sont ignorés partout, sans réglage : ils
naissent et meurent avec le job, et leur état n'est pas celui de la machine.

## Lire une alerte

Chaque alerte montre **quoi** et **combien** : le disque, le service ou le
certificat touché, la valeur mesurée avec son unité, et le repère auquel
elle se compare — seuil, habitude ou plancher. Une jauge situe la valeur
quand la grandeur est bornée (un disque à 90,6 % pour un seuil à 90 %), une
échéance s'affiche pour une saturation prévue (« Plein dans 38 h »). Juste
dessous, **Comprendre et agir** dit ce que ça casse, quoi faire, et donne
les commandes de lecture qui le vérifient.