Exemple d'alerte
Ces exemples montrent le contenu exact d'alertes fictives CashFlowCanary : assez court pour agir vite, assez précis pour orienter l'équipe, sans donnée client réelle.
Exemple de message envoyé à une équipe de supervision. Les destinataires et identifiants restent masqués.
[CashFlowCanary] Incident checkout à traiter — Boutique démo — Paiement refusé
Incident ouvert à 09:14. Étape touchée : checkout paiement. Verdict : à traiter. Preuve : la page répond, mais la finalisation échoue. Prochaine action : vérifier méthode de paiement, cache checkout et dernier changement WooCommerce.
Le message pointe vers le cockpit et vers une preuve filtrée quand le plan autorise le partage. Aucun email client, panier détaillé, carte ou payload brut n'est envoyé.
Format plus court pour alerter immédiatement l'équipe, sans sacrifier la prochaine action.
CashFlowCanary — Incident checkout à traiter. Boutique démo. Étape : paiement. Signal : finalisation impossible. Priorité : haute. Action : vérifier moyen de paiement actif puis relancer le check.
Telegram sert au signal rapide. Le diagnostic complet, les preuves et la résolution restent dans le cockpit ou le PDF selon le plan.
Le message ne contient pas d'adresse client, de panier détaillé, de token, de clé API, de carte ou de capture sensible.
Anti-spam produit
Quand un incident a déjà été envoyé, CashFlowCanary évite de répéter la même alerte tant que les tests ne repassent pas au vert. Un client peut toujours déclencher une action manuelle depuis le cockpit.
L'alerte ne prétend pas corriger la boutique. Elle prouve qu'une étape qui encaisse est cassée, indique la priorité et donne la prochaine action vérifiable.