# Notifications d'exploitation Une instance en fonctionnement informe ses exploitants à son propre sujet par e-mail, sans que personne n'ouvre la console. Il existe deux e-mails de ce type : - **Alertes d'automatisation** — envoyées lorsqu'une automatisation échoue après sa dernière relance, dépasse son délai, est interrompue par un redémarrage du serveur, ou est mise en pause ou reprise. - **Synthèse hebdomadaire** — une fois par semaine, ce qu'ont fait les automatisations, les données et l'instance, comparé à la semaine précédente, et ce qui attend un exploitant. Les deux sont gratuits et intégrés au binaire. Les deux exigent une distribution d'e-mails fonctionnelle, configurée avec les variables `SMTP_*`, et les deux gagnent à ce que `BASE_URL` soit définie : c'est elle qui rend absolus les liens qu'ils contiennent. Sans elle, les e-mails partent quand même, sans liens. ## Qui les reçoit Chaque e-mail a son propre public, résolu de la même façon : 1. Chaque compte de niveau administrateur de l'application — chaque rôle qu'admet la console d'exploitation — qui n'est pas banni et a laissé cet e-mail **activé** dans son profil. Seules les applications qui déclarent un bloc `auth:` ont des comptes. 2. Chaque adresse listée dans `SOVRIUM_NOTIFY_TO`, quoi que déclare l'application. Pour une application sans bloc `auth:`, ces adresses constituent tout le public. Une adresse qui figure aux deux endroits ne reçoit qu'un seul envoi. Chaque compte possède ses deux interrupteurs, **Automation alerts** et **Weekly summary**, sur sa page de profil dans la console (`/_admin/profile`) ; les deux sont activés au départ, et en désactiver un fait taire cet e-mail pour ce seul compte. Chaque e-mail d'exploitation renvoie vers cette page. ## Alertes d'automatisation Le premier échec définitif d'une automatisation est envoyé immédiatement, en nommant l'automatisation, l'exécution et l'erreur. Les échecs suivants de la même automatisation dans l'heure qui suit sont retenus et regroupés dans **une synthèse horaire** qui indique combien de fois de plus elle a échoué, sa dernière erreur, et à quel moment elle s'est rétablie si une exécution ultérieure a réussi. Une synthèse perdue lors d'un redémarrage n'est pas rattrapée : chaque automatisation qu'elle contenait avait déjà vu son premier échec envoyé par e-mail. Une exécution encore en cours lorsque le serveur s'est arrêté est clôturée au démarrage suivant comme échouée, avec l'erreur `Interrupted: the server stopped during this run`, et signalée comme tout autre échec. Mettre en pause ou reprendre une automatisation depuis la console envoie un e-mail aux autres destinataires, en nommant l'auteur de l'action. Avec `SOVRIUM_AUTOMATION_AUTOPAUSE=`, la plateforme met elle-même une automatisation en pause après `n` échecs définitifs d'affilée, et le signale par e-mail. Sans valeur — le défaut —, rien n'est jamais mis en pause automatiquement. ## La synthèse hebdomadaire La synthèse part selon `SOVRIUM_NOTIFY_DIGEST_CRON` — le lundi à 08:00 par défaut —, lu dans le fuseau de l'exploitant, `SOVRIUM_TIMEZONE`. Sa période commence exactement là où la synthèse précédente s'est arrêtée : des synthèses consécutives ne laissent donc aucun trou et ne comptent rien deux fois ; chaque date qu'elle contient est écrite selon le calendrier de l'exploitant, et l'e-mail nomme le fuseau. Elle rapporte : - **Automatisations** — exécutions, échecs (dont dépassements de délai et interruptions), taux de réussite, les cinq automatisations qui ont le plus échoué avec, pour chacune, sa dernière erreur résumée, et chaque automatisation en pause, les pauses automatiques étant signalées. - **Données** — lignes par table et lignes distinctes écrites pendant la semaine, comptes créés, comptes qui se sont connectés, soumissions de formulaires, et fichiers téléversés avec leur taille. - **Instance** — taille de la base de données et du stockage de fichiers, nombre de connexions en bonne santé, changements de version du moteur, et entrées d'audit d'erreur et critiques regroupées par action, les cinq plus fréquentes. - **En attente de vous** — variables d'environnement non définies, jetons de connexion expirés, invitations en attente. Chaque synthèse est conservée, afin que la suivante puisse présenter les nombres de lignes et les tailles comme des évolutions par rapport à elle. La toute première synthèse qu'envoie une instance couvre les sept jours qui la précèdent et est marquée comme **semaine de référence** : il n'y a encore rien à comparer. **Ce qu'elle ne contient jamais.** La synthèse porte des décomptes, ainsi que les noms de vos tables, automatisations et actions d'audit. Elle ne contient jamais une valeur d'enregistrement, une valeur soumise, l'adresse e-mail d'un compte ni son nom. Le seul texte libre est la dernière erreur d'une automatisation en échec, résumée comme dans les e-mails d'alerte : sa première ligne seulement, le bloc de détail d'une base de données retiré sauf la colonne que nomme une clé dupliquée, dont la valeur est remplacée (`Key (email)=(…)`), tout mot de passe d'une URL de connexion masqué, le tout plafonné à 200 caractères. Cela reste l'erreur qu'a renvoyée un service en amont : gardez donc les secrets hors de ce que vos intégrations renvoient. **Quand le serveur était arrêté.** Au démarrage, une synthèse en retard de plus d'une semaine est rattrapée par **une seule** synthèse couvrant toute la période manquée, et non une par semaine manquée. Une synthèse récente dont l'envoi a échoué est envoyée à nouveau. Une instance qui n'en a encore jamais envoyé attend sa première exécution planifiée. **Instance unique.** Le rattrapage au démarrage et le balayage des exécutions interrompues supposent chacun être le seul serveur sur la base de données. Deux serveurs partageant une même base enverraient tous deux le rattrapage et pourraient clôturer les exécutions en cours l'un de l'autre ; n'en faites tourner qu'un. ## Variables | Variable | Par défaut | Effet | | ------------------------------ | ----------- | ------------------------------------------------------------------------------------------------------ | | `SOVRIUM_NOTIFY_AUTOMATIONS` | `on` | `off` coupe toutes les alertes d'automatisation pour toute l'instance | | `SOVRIUM_NOTIFY_DIGEST` | `weekly` | `off` coupe la synthèse hebdomadaire pour toute l'instance, et rien n'est stocké ni rattrapé | | `SOVRIUM_NOTIFY_DIGEST_CRON` | `0 8 * * 1` | Moment d'envoi de la synthèse, en expression cron à cinq champs dans le fuseau de l'exploitant | | `SOVRIUM_NOTIFY_TO` | non définie | Adresses supplémentaires, séparées par des virgules, qui reçoivent les deux e-mails | | `SOVRIUM_AUTOMATION_AUTOPAUSE` | non définie | Met une automatisation en pause après ce nombre d'échecs définitifs d'affilée ; non définie, jamais | | `SOVRIUM_TIMEZONE` | `UTC` | Le fuseau dans lequel la synthèse est planifiée et ses dates écrites | | `BASE_URL` | non définie | L'origine publique à partir de laquelle chaque lien de ces e-mails est construit | Chacune est validée au démarrage. Une valeur erronée — `SOVRIUM_NOTIFY_DIGEST=daily`, une expression cron à six champs, une entrée de `SOVRIUM_NOTIFY_TO` qui n'est pas une adresse e-mail — empêche le serveur de démarrer, en nommant la variable et la valeur, plutôt que d'échouer en silence la semaine où l'e-mail est dû. En modifier une prend effet au redémarrage suivant.