Statut et incidents
Neuf services sondés, un historique consolidé sur 90 jours, la façon dont les incidents sont publiés, et trois moyens d'être prévenu sans surveiller une page.
La page /status est publique et ne demande aucun compte.
Ce qui est sondé
Neuf services, vérifiés chacun indépendamment :
platform · api · authentication · database · aiGateway ·
backgroundJobs · fileStorage · emailDelivery ·
shopifyIntegration
Ils sont sondés séparément, et c'est voulu. « La plateforme fonctionne » n'est pas une réponse utile pour quelqu'un dont la synchronisation Shopify échoue.
L'historique
Toutes les 30 minutes, un cron d'instantané consolide les sondes dans un relevé quotidien qui retient le pire état. Le pire plutôt que la moyenne : une journée avec 40 minutes de panne doit se lire comme une mauvaise journée, pas comme 97 % d'une bonne.
La page affiche 90 jours de barres quotidiennes, et
/status/history donne un bilan mensuel sur 12 mois.
Incidents
Un incident est déclaré par un opérateur et passe par
investigating → identified → monitoring → resolved, avec l'un de trois
niveaux de gravité : mineur, majeur, critique.
Trois moyens d'être prévenu
Abonnement par e-mail sur /status. Double opt-in, avec un jeton de
désinscription en un clic dans chaque message.
RSS : /status/incidents.rss, les 90
derniers jours.
Webhooks : sortants, signés en HMAC-SHA256, pour les événements d'incident. Ils se configurent depuis l'espace d'administration ; la vérification est décrite dans Webhooks.
Pour vos propres tableaux de bord
GET /api/status/summary est public et mis en cache 60 secondes. Il
renvoie un état, un compte et un horodatage, et volontairement aucun
détail d'incident. Il sert à alimenter une pastille de statut dans un
pied de page, pas à tenir lieu de flux d'incidents : pour cela, utilisez
le RSS ou un webhook.