Observatoire d’automatisation Datvero · slack-status.com
Non. La page de statut de Slack indique que tous les systèmes sont opérationnels pour Slack : Messaging, Login/SSO, Apps/Integrations/APIs et 8 autres composants (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 Slack le 6 novembre 2026, 18:15 UTC. Datvero republie ce que Slack déclare ; ce n’est pas une mesure de disponibilité indépendante.
Du 8 mai au 6 novembre 2026, slack-status.com recense 30 incidents. Durée médiane entre la première publication et la dernière mise à jour, incidents résolus dont la durée est publiée : 2,8 h. Le plus long : « Trouble Accessing Historical Messages With Custom Data Retention Policies Enabled » (13 août 2026), 32 jours. Sur les 30 derniers jours : 3 incidents, dont 0 panne.
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 Slack indique que tous les systèmes sont opérationnels pour Slack : Messaging, Login/SSO, Apps/Integrations/APIs et 8 autres composants (relevé le 6 novembre 2026, 18:15 UTC ; cette page se rafraîchit toutes les 5 minutes).
Du 8 mai au 6 novembre 2026, slack-status.com recense 30 incidents. Durée médiane entre la première publication et la dernière mise à jour, incidents résolus dont la durée est publiée : 2,8 h. Le plus long : « Trouble Accessing Historical Messages With Custom Data Retention Policies Enabled » (13 août 2026), 32 jours. Sur les 30 derniers jours : 3 incidents, dont 0 panne.
Slack la publie sur https://slack-status.com/. Cette page republie son flux public toutes les 5 minutes, avec les horodatages. Datvero n’est pas affilié à Slack.
Quand la page de statut est verte mais que votre app ou webhook Slack échoue, lisez le code HTTP. Si vous dépassez une limite de débit sur l’une des API HTTP de Slack, webhooks entrants compris, Slack renvoie HTTP 429 Too Many Requests avec un en-tête Retry-After qui donne le nombre de secondes avant de pouvoir réessayer. C’est une limite, pas une panne.
La page de statut liste ce que Slack 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 Slack réussit.
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 Status de Slack (slack-status.com/api/v2.0.0, documentée sur https://docs.slack.dev/reference/slack-status-api/) est lue toutes les 5 minutes : le point d’accès current pour les incidents actifs, le point d’accès history pour les incidents passés. Une durée va de la première publication à la dernière mise à jour d’un incident résolu ; elle n’est affichée que si l’incident compte au moins deux publications. Copie lisible par machine : services.json. Codes HTTP : Slack developer docs, Rate limits. Source officielle : https://slack-status.com/.
Les statuts, noms d’incident et textes appartiennent à Slack et sont publiés en anglais. Datvero n’est pas affilié à Slack. Une page de statut verte ne signifie pas que tous les workflows qui appellent Slack réussissent.