Plateforme

L'endroit où aller quand quelque chose ne va pas. Voici les outils dont la sortie se lit facilement de travers.

Moniteur cron

Les jobs déclarés dans vercel.json, leur historique d'exécution, et un déclenchement manuel.

Consultez-le avant de conclure qu'un chiffre affiché ailleurs est faux. Beaucoup de tuiles de l'admin lisent des tables qu'un cron remplit, et une table figée s'affiche exactement comme une activité calme. Un job qui n'a pas tourné est le plus fréquent des deux cas.

Observabilité et signaux qui ressemblent à des pannes

Sondes d'infrastructure (Postgres, Upstash, Stripe, Resend), plus l'état des déploiements.

Deux signaux ressemblent à des pannes de code et n'en sont pas :

• Quota QStash. discovery-harvest-tick se replie sur le traitement de quelques boutiques en ligne au lieu d'en répartir des milliers. Le jeton est valide ; c'est l'allocation du plan qui est épuisée. Elle se réinitialise à minuit UTC.
• GitHub Actions qui ne démarre pas. Chaque workflow échoue en 1 à 4 secondes, sans runner ni étape, les logs de job répondent 404, sur chaque branche et sur main à l'identique. Lis l'annotation du check-run : le 2 octobre 2026 elle disait « The job was not started because recent account payments have failed or your spending limit needs to be increased ». C'est la facturation GitHub (Billing & plans), à la main du propriétaire, et elle ne revient pas seule. Aucun code n'est en cause ; tant que ça dure, aucune PR n'a de CI. Un vrai échec dure des dizaines de secondes et produit des logs.

Ce qui trahit le second : le déploiement Vercel du même commit passe Ready pendant que le build Actions « échoue » en trois secondes. Deux verdicts opposés sur le même code signifient que le second n'a rien compilé.

Intégrité des données

Détecte et répare les dérives : utilisateurs en double, lignes OrganizationMember manquantes. La réparation écrit dans les tables de production, donc lisez ce qu'elle propose avant de l'accepter.

Statut

Déclarer un incident ici, c'est ce que voient la page publique /status et les abonnés par e-mail. C'est une communication client, pas une note pour soi : les abonnés sont notifiés, et le flux RSS le relaie.

Neuf services sont sondés indépendamment, et le cumul quotidien retient le pire état plutôt qu'une moyenne : une journée avec une panne de 40 minutes se lit comme une mauvaise journée, ce qui est le rendu honnête.

Variables d'environnement

Les variables serveur que la plateforme attend, et leur état SET / MISSING. Aucune valeur n'est affichée, par conception. Bien plus souvent qu'un bug, c'est une clé manquante ici qui explique une fonctionnalité qui ne fait rien, en silence.

Pool de dev stores

Les dev stores Shopify pré-provisionnés dans lesquels puise le wizard clé en main. Un pool vide ne casse pas le wizard : le client est mis en liste d'attente et le parcours continue. Cela veut quand même dire que personne n'obtient de boutique tant que le pool n'est pas réapprovisionné, et le client n'est pas prévenu du moment où il le sera.