SESPULSE : un tableau de bord self-hosted pour Amazon SES
📌 SESPULSE est un dashboard self-hosted qui récupère les événements d’Amazon SES via SQS et affiche les taux de livraison, les rebonds, les ouvertures et les clics dans une interface locale.
Amazon SES est efficace pour envoyer des emails, mais difficile à surveiller par message. CloudWatch donne des agrégats globaux, et SNS envoie du JSON brut. Quand un email n’arrive pas, vous n’avez aucun moyen simple de retrouver ce qui s’est passé sans fouiller dans des logs illisibles. SESPulse garde une copie locale de chaque événement dans Postgres pour répondre à ces questions depuis un tableau de bord.
Le choix architectural central est l’utilisation de SQS plutôt que d’un webhook. SES publie les événements vers SNS, SNS les pousse dans une file SQS, puis le worker de SESPulse interroge la file en long-polling et écrit dans Postgres. Ce modèle évite d’exposer un endpoint public avec TLS, de gérer les confirmations d’abonnement SNS et de mettre en place un système de déduplication manuel. La file SQS bufferise les événements pendant les redéploiements, et le worker déduplique automatiquement via le MessageId de SNS.
L’interface affiche une vue d’ensemble avec les taux de livraison, de rebond, de plainte, d’ouverture et de clic. Les cartes changent de couleur selon les seuils de réputation de SES : au-delà de 5 % de rebonds ou 0,1 % de plaintes, la zone passe au rouge. Un graphique temporel montre les envois et rebonds heure par heure sur 24 heures, ou jour par jour sur 7 et 30 jours.
Quelques fonctions concrètes :
- 📊 Vue d’ensemble avec taux de livraison, rebonds, plaintes, ouvertures et clics
- 🌐 Répartition par domaine d’envoi pour repérer les sources problématiques
- 🔍 Logs recherchables par domaine, type d’événement ou texte libre
- 📋 Chronologie complète par message avec diagnostics de rebond et payload brut
- 🔔 Tous les types d’événements SES : Send, Delivery, Bounce, Complaint, Open, Click, Reject, DeliveryDelay
- 🔄 Rafraîchissement automatique toutes les 30 secondes pendant un incident
Je trouve l’approche par domaine particulièrement pertinente. Si une de vos applications commence à générer des rebonds sur un domaine spécifique, vous pouvez l’isoler avant qu’elle ne dégrade le score de réputation global de votre compte SES. Le fait de pouvoir cliquer sur un message et de voir sa chronologie complète — envoi, livraison, ouverture, clic ou rebond avec le diagnostic — répond au besoin quotidien de support quand un utilisateur signale qu’il n’a pas reçu son email.
La configuration reste accessible pour un projet qui touche à AWS. La mise en route demande de créer un topic SNS, une file SQS, d’attacher les politiques IAM appropriées et d’activer un configuration set dans SES. Ensuite, un docker compose up -d --build démarre Postgres, le worker et le dashboard Next.js. Des variables d’environnement optionnelles permettent d’activer une authentification et de configurer l’intervalle de rafraîchissement.
Le projet est très jeune : 8 commits, aucune release publiée et quelques fonctionnalités encore sur la feuille de route, comme les alertes Slack ou l’export CSV. La confidentialité est clairement énoncée : les données d’email circulent uniquement entre votre compte AWS et votre Postgres, sans aucun envoi vers un tiers. Un endpoint de health check est disponible pour le brancher sur UptimeRobot ou BetterStack.
SESPULSE s’adresse aux équipes qui envoient des emails transactionnels via SES et qui veulent une visibilité par message sans construire leur propre pipeline. Ce n’est pas un outil de marketing email, mais un instrument de diagnostic et de surveillance de la délivrabilité. Pour qui dépend de SES en production, c’est le genre de dashboard qui devrait exister par défaut.
Sources
