Observatoire d’automatisation Datvero · status.supabase.com
Non. La page de statut de Supabase indique que tous les systèmes sont opérationnels pour Supabase : ap-east-1 (relevé le 6 novembre 2026, 18:15 UTC ; cette page se rafraîchit toutes les 5 minutes).
Lu sur l’API de statut officielle de Supabase le 6 novembre 2026, 18:15 UTC. Datvero republie ce que Supabase déclare ; ce n’est pas une mesure de disponibilité indépendante.
Du 22 septembre au 6 novembre 2026, status.supabase.com recense 30 incidents : 1 critique, 3 majeurs, 18 mineurs et 8 sans impact (classification de l’éditeur). Durée médiane entre la première publication et la résolution, incidents avec impact uniquement : 1,3 h. Le plus long : « Intermittent latency in Eastern US » (29 septembre 2026), 6,8 jours. Sur les 30 derniers jours : 20 incidents, dont 3 de gravité majeure ou critique.
Réessayez avec un délai croissant, envoyez les échecs vers un workflow d’erreur et soyez alerté quand les exécutions cessent de réussir. Dans n8n, chaque nœud a un réglage Retry On Fail ; Make propose des gestionnaires d’erreur Break qui relancent les exécutions incomplètes ; Zapier peut rejouer les exécutions échouées avec Autoreplay. Datvero surveille les exécutions de vos workflows n8n, Make et Zapier et vous alerte quand elles échouent, quelle qu’en soit la cause.
Non. La page de statut de Supabase indique que tous les systèmes sont opérationnels pour Supabase : ap-east-1 (relevé le 6 novembre 2026, 18:15 UTC ; cette page se rafraîchit toutes les 5 minutes).
Du 22 septembre au 6 novembre 2026, status.supabase.com recense 30 incidents : 1 critique, 3 majeurs, 18 mineurs et 8 sans impact (classification de l’éditeur). Durée médiane entre la première publication et la résolution, incidents avec impact uniquement : 1,3 h. Le plus long : « Intermittent latency in Eastern US » (29 septembre 2026), 6,8 jours. Sur les 30 derniers jours : 20 incidents, dont 3 de gravité majeure ou critique.
Supabase la publie sur https://status.supabase.com/. Cette page republie son flux public toutes les 5 minutes, avec les horodatages. Datvero n’est pas affilié à Supabase.
La page de statut liste ce que Supabase a déclaré. Si elle est verte et que vous voyez quand même des erreurs, lisez le code d’erreur, réessayez avec un délai croissant et vérifiez si le problème est propre à votre compte, à votre région ou à une intégration. Une page verte ne prouve pas que chaque requête vers Supabase réussit.
Datvero montre ce que publie le flux de statut public de Supabase. Ce flux ne liste qu’un seul composant et ne rattache aucun composant à ses incidents : la colonne des composants du tableau d’incidents est donc vide. Ouvrez status.supabase.com pour la vue complète des services.
Réessayez avec un délai croissant, envoyez les échecs vers un workflow d’erreur et soyez alerté quand les exécutions cessent de réussir. Dans n8n, chaque nœud a un réglage Retry On Fail ; Make propose des gestionnaires d’erreur Break qui relancent les exécutions incomplètes ; Zapier peut rejouer les exécutions échouées avec Autoreplay. Datvero surveille les exécutions de vos workflows n8n, Make et Zapier et vous alerte quand elles échouent, quelle qu’en soit la cause.
Méthode : l’API de statut publique de Supabase (status.supabase.com/api/v2) est lue toutes les 5 minutes, sa liste d’incidents au plus toutes les 15 minutes, et chaque incident est conservé avec ses horodatages officiels. Les durées vont de la première publication à la publication de résolution. Copie lisible par machine : services.json. Source officielle : https://status.supabase.com/.
Les statuts, noms d’incident et textes appartiennent à Supabase et sont publiés en anglais. Datvero n’est pas affilié à Supabase. Une page de statut verte ne signifie pas que tous les workflows qui appellent Supabase réussissent.