Tous les systèmes fonctionnent
Dernière vérification il y a une minute. Les vérifications ont lieu toutes les 5 minutes.
Composants
Une vraie page de boutique est rendue dans le worker, et une clé est écrite puis relue dans le cache de périphérie.
L’API d’administration répond à une requête sans identifiants par le refus attendu, ce qui prouve qu’elle est bien vivante.
Un appel en lecture seule à l’API Stripe. La vérification ne crée jamais de paiement.
Une ligne est écrite puis relue dans la base de données qui contient les commandes.
Un appel en lecture seule à l’API du service d’e-mail, qui indique aussi combien de messages ont échoué ou ont été marqués comme spam. La vérification n’envoie aucun e-mail.
Un petit objet est écrit dans le stockage d’objets puis relu avec une requête HEAD.
Un appel en lecture seule à l’API Cloudflare qui émet et renouvelle les certificats.
L’API publique versionnée répond à une requête avec un jeton invalide par le refus attendu.
L’exécution planifiée écrit un signe de vie ; la vérification regarde depuis combien de temps.
S’abonner aux alertes
Un e-mail quand un incident est ouvert, mis à jour ou résolu. Nous envoyons d’abord un lien de confirmation, et chaque e-mail contient un lien de désabonnement.
Ce que nous mesurons, et comment
Rien sur cette page n’est basculé à la main. Toutes les 5 minutes, la plateforme lance une vraie vérification de chaque composant depuis notre propre infrastructure et note si elle a réussi et combien de temps elle a pris.
- Boutiques — Une vraie page de boutique est rendue dans le worker, et une clé est écrite puis relue dans le cache de périphérie.
- Panneau d’administration — L’API d’administration répond à une requête sans identifiants par le refus attendu, ce qui prouve qu’elle est bien vivante.
- Commande et paiements — Un appel en lecture seule à l’API Stripe. La vérification ne crée jamais de paiement.
- Traitement des commandes — Une ligne est écrite puis relue dans la base de données qui contient les commandes.
- Envoi des e-mails — Un appel en lecture seule à l’API du service d’e-mail, qui indique aussi combien de messages ont échoué ou ont été marqués comme spam. La vérification n’envoie aucun e-mail.
- Images et fichiers — Un petit objet est écrit dans le stockage d’objets puis relu avec une requête HEAD.
- Domaines personnalisés et SSL — Un appel en lecture seule à l’API Cloudflare qui émet et renouvelle les certificats.
- API et webhooks — L’API publique versionnée répond à une requête avec un jeton invalide par le refus attendu.
- Tâches planifiées — L’exécution planifiée écrit un signe de vie ; la vérification regarde depuis combien de temps.
Une seule vérification échouée ne change jamais la page : un composant n’est marqué comme dégradé qu’après deux échecs consécutifs, et comme indisponible après quatre. Il redevient normal après trois vérifications réussies. Nous regardons en plus la part de requêtes en échec pour les vrais visiteurs : un composant peut donc être dégradé même quand notre propre vérification passe.
La disponibilité est la part de vérifications réussies sur la période, regroupée par jour. Les jours antérieurs au début des mesures, et les vérifications d’un service non configuré, apparaissent comme « pas de données » et ne comptent pas. Les heures sont en UTC. Cette page n’affiche jamais de noms de boutiques, de données clients ni de messages d’erreur internes.
Aucun incident signalé ces 90 derniers jours.