Notification Hub

1. Quoi ? — Définition et contexte

Le Notification Hub est le workflow N8N qui centralise toutes les notifications de l’infrastructure. Il applique des règles intelligentes : déduplication, quiet hours, escalade, et routage multi-canal.

Sources de notifications

Source	Type d’événements
Docker DIUN	Nouvelles versions d’images
Alertmanager	Alertes Prometheus (CPU, RAM, disk)
Health Check	Status des services
Workflows N8N	Résultats d’exécution, erreurs

Canaux de sortie

Canal	Usage
Telegram	Principal, notifications interactives
ntfy	Backup push mobile
Discord	Optionnel, pour équipes

2. Pourquoi ? — Enjeux et motivations

Problèmes résolus

Problème	Sans hub	Avec hub
Spam de notifications	Chaque service notifie indépendamment	Point unique de sortie contrôlé
Doublons	Même alerte envoyée plusieurs fois	Déduplication par clé + TTL
Alertes nocturnes	Réveillé pour un warning	Quiet hours pour non-critiques
Pas d’audit	Notifications perdues	Historique complet en base

Fonctionnalités clés

Fonction	Bénéfice
Déduplication	Évite les notifications en double sur une fenêtre de temps
Quiet Hours	Notifications non-critiques différées 22h-8h
Multi-canal	Telegram + ntfy + Discord selon la sévérité
Historique	Toutes les notifications stockées pour audit
Escalade	Alertes non acquittées passent en critique

3. Comment ? — Mise en œuvre technique

Architecture

┌─────────────────────────────────────────────────────────┐
│                  Sources de notifications                │
├─────────────────────────────────────────────────────────┤
│  Docker DIUN       Alertmanager        Health Check     │
│  (image updates)   (Prometheus)        (scheduled)      │
│        │                │                   │           │
│        └────────────────┼───────────────────┘           │
│                         ▼                               │
│              ┌────────────────────────┐                 │
│              │    Notification Hub    │                 │
│              │    (workflow central)  │                 │
│              └───────────┬────────────┘                 │
│                          │                              │
│          ┌───────────────┼───────────────┐              │
│          ▼               ▼               ▼              │
│      Telegram         ntfy           Discord            │
└─────────────────────────────────────────────────────────┘

Workflow détaillé

Notification entrante
         │
         ▼
┌─────────────────────────────────────────────────────────┐
│  1. Validation du payload                                │
│     - Type requis                                       │
│     - Severity valide                                   │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  2. Déduplication                                        │
│     - Calcul clé de dédupe                              │
│     - Check Redis                                       │
│     - Skip si doublon                                   │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  3. Quiet Hours                                          │
│     - Check heure actuelle                              │
│     - Différer si non-critique + nuit                   │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  4. Formatage                                            │
│     - Template par type et canal                        │
│     - Ajout metadata contextuelles                      │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  5. Envoi multi-canal                                    │
│     - Telegram (toujours)                               │
│     - ntfy (si critical)                                │
│     - Discord (si configuré)                            │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  6. Historisation                                        │
│     - Sauvegarde en base                                │
│     - Update Redis dédupe                               │
└─────────────────────────────────────────────────────────┘

Déduplication

// Clé de déduplication
const dedupeKey = `${type}:${container}:${severity}`;

// TTL variable selon la sévérité
const ttl = {
  info: 3600,      // 1 heure
  warning: 1800,   // 30 min
  critical: 300    // 5 min
};

// Vérifier si déjà envoyé
const existing = await redis.get(dedupeKey);
if (existing) {
  return { skipped: true, reason: 'duplicate' };
}

// Marquer comme envoyé
await redis.set(dedupeKey, Date.now(), { EX: ttl[severity] });

Quiet Hours

Heure	Info	Warning	Critical
08h-22h	Immédiat	Immédiat	Immédiat
22h-08h	Queue	Queue	Immédiat

const isQuietHours = hour >= 22 || hour < 8;
const isCritical = severity === 'critical';

if (isQuietHours && !isCritical) {
  // Différer jusqu'à 8h
  return { deferred: true, sendAt: '08:00' };
}

Format d’entrée

{
  "type": "update_success",
  "severity": "info",
  "title": "Docker Update réussi",
  "message": "n8n-stack mis à jour vers 1.73.0",
  "container": "n8n",
  "image": "n8nio/n8n:1.73.0",
  "project": "n8n-stack",
  "timestamp": "2026-01-20T10:30:00.000Z",
  "metadata": {
    "duration_seconds": 45,
    "previous_version": "1.72.0"
  }
}

Types supportés

Type	Description	Sévérité par défaut
`update_success`	Docker update réussi	info
`update_failed`	Docker update échoué	critical
`update_queued`	Update programmé	info
`approval_request`	Demande d’approbation	warning
`alert_prometheus`	Alerte Prometheus	variable
`container_down`	Conteneur arrêté	critical

Appel du hub

Depuis un workflow N8N :

// Execute Workflow node
{
  "workflowId": "notification-hub",
  "mode": "execute",
  "inputData": {
    "type": "update_success",
    "severity": "info",
    "title": "...",
    "message": "..."
  }
}

Via webhook interne :

curl -X POST http://n8n:5678/webhook/notification-hub \
  -H "Content-Type: application/json" \
  -d '{
    "type": "custom",
    "severity": "info",
    "title": "Test notification",
    "message": "Hello from curl"
  }'

Historique

Colonne	Type	Description
`id`	UUID	Identifiant unique
`type`	Text	Type de notification
`severity`	Text	info / warning / critical
`payload`	JSON	Contenu complet
`channels`	Array	Canaux utilisés
`sent_at`	Timestamp	Date d’envoi
`deferred`	Boolean	Si différé
`dedupe_key`	Text	Clé de déduplication

4. Et si ? — Perspectives et limites

Limites actuelles

Limite	Impact	Mitigation
Redis single-instance	Perte du cache si Redis down	Notification envoyée (pas de dédupe)
Pas d’escalade automatique	Alertes non acquittées restent warning	Prévu mais non implémenté
Quiet hours fixes	Pas de configuration par utilisateur	Suffisant pour usage solo

Scénarios d’évolution

Si besoin d’escalade automatique :

Tracker les alertes non acquittées
Après délai configurable, passer en critical
Optionnel : appel téléphonique via Twilio

Si volume de notifications augmente :

Agrégation par batch (résumé toutes les heures)
Digest quotidien pour les infos non urgentes
Filtrage par abonnement (opt-in par type)

Si équipe multi-utilisateurs :

Configuration quiet hours par utilisateur
Routage vers le bon canal selon l’utilisateur de garde
Gestion des acquittements partagés

Pages liées

Infrastructure

N8N en mode Queue — Backend automation
Monitoring Stack — Source Prometheus

Workflows

Telegram Orchestrator — Réception callbacks
Docker Auto-Updates — Source DIUN

Référence

Glossaire — Webhook, Deduplication