Le problème vient du service ou de votre connexion ? Vérifions ensemble.
Commencez par le service que vous utilisez, puis consultez les éléments qui correspondent à votre problème. Inutile de lire tous les graphiques pour savoir quoi essayer ensuite.
Utilisez l'état du service pour une application prise en charge, ou la vérification de site pour une adresse publique. L'un présente les informations du fournisseur ; l'autre vérifie la réponse d'une page précise.
Lisez d'abord les incidents en cours. Ouvrez les composants pour examiner la connexion, les envois de fichiers ou une API. La dernière mise à jour peut préciser les utilisateurs concernés.
Actualisez les informations avant de décider. Copiez ou téléchargez un rapport daté pour l'assistance. Partagez plutôt le lien si votre interlocuteur a besoin d'une nouvelle vérification.
Une page d'accueil accessible ne garantit pas le fonctionnement de la connexion. Consultez le composant et l'incident correspondant avant de modifier votre mot de passe ou d'effacer des données utiles du navigateur.
Cherchez les incidents liés aux parties en ligne, à la messagerie ou à l'application. Sans panne annoncée, comparez si possible le Wi-Fi et les données mobiles. Un seul appareil en difficulté ne prouve pas une panne mondiale.
Sélectionnez le produit concerné, pas seulement l'entreprise qui le propose. Vérifiez le composant et l'heure de l'erreur, puis conservez un rapport avec votre identifiant de requête. Ne saisissez jamais de clé API ni de lien signé ici.
Lisez la dernière mise à jour et la période de maintenance avant de réessayer. Évitez de soumettre plusieurs fois un paiement ou un fichier : une réponse tardive ne signifie pas forcément que la première tentative a échoué.
Choisissez le type de vérification avant de lancer la recherche. Vous pouvez garder jusqu'à cinq services en favoris dans ce navigateur, filtrer par catégorie ou afficher uniquement les problèmes signalés. L'actualisation automatique concerne les sources officielles tant que la page est visible ; un site est vérifié une seule fois. Le filtre des composants permet de retrouver une fonction ou une région. Copiez le rapport pour conserver l'heure de l'observation, ou partagez un lien vers une nouvelle vue. Les fichiers PNG, texte et JSON présentent les données disponibles, sans prédire l'heure du rétablissement.
Un service ne se résume pas à sa page d'accueil.
La première page affichée peut être indépendante des comptes, de la recherche, de la messagerie, du stockage de fichiers ou des paiements. Une panne partielle est donc possible : la page publique s'ouvre normalement, mais l'action dont vous avez besoin échoue. Une vérification de site réussie et un composant défaillant peuvent ainsi être deux constats exacts.
Notre Down Detector distingue ces observations. L'état du service reprend les informations publiées par le fournisseur ; la vérification de site examine une adresse publique à un instant donné. Aucun des deux ne teste votre compte privé, un paiement authentifié ou toutes les régions. En cas de divergence, appuyez-vous sur la description de l'incident pour identifier la fonction concernée, plutôt que sur une seule étiquette.
Pour comprendre la différence entre symptômes et causes, le guide de Google sur la surveillance des systèmes distribués explique pourquoi une observation externe et une mesure interne peuvent éclairer des aspects différents du même problème.
Les mises à jour racontent une évolution, pas seulement une couleur.
Une investigation signifie généralement que le fournisseur évalue le problème. Une cause identifiée indique qu'il a précisé son origine. La surveillance signifie qu'une modification a été apportée et que ses effets sont suivis ; ce n'est pas une garantie de rétablissement pour tous. La résolution correspond à la clôture de l'incident par le fournisseur. Une analyse ultérieure peut expliquer les causes et les mesures prévues.
Une annonce peut arriver après les premiers problèmes rencontrés par les utilisateurs, et chaque session ne se rétablit pas nécessairement au même moment. Nous affichons la dernière mise à jour disponible et les composants concernés lorsqu'ils sont précisés, en séparant les incidents en cours de l'historique. La maintenance planifiée dispose d'un espace distinct. Lorsqu'un incident n'est pas attribué à un produit, nous signalons cette incertitude sans conclure à une panne générale.
Vous pouvez comparer ces éléments au dossier du fournisseur : la documentation publique de l'état de Cloudflare distingue notamment incidents, état des composants et maintenance planifiée.
Examinez la réponse avant de choisir une solution.
Pas nécessairement. Une réponse 404 peut indiquer qu'une page a été déplacée, alors que le reste du site fonctionne. Une réponse 403 peut provenir d'une restriction d'accès ou d'une protection contre les requêtes automatisées. Une erreur serveur, une absence de réponse DNS ou un délai dépassé indiquent davantage un problème pour cette requête, mais ne démontrent ni une panne mondiale ni sa cause.
Si une seule adresse échoue, essayez la page d'accueil. Si plusieurs sites sans lien entre eux échouent sur votre appareil, vérifiez votre connexion et comparez un autre réseau. Si la page d'accueil fonctionne mais pas une action, consultez les composants et le message d'erreur exact. Gardez l'heure, l'action et le résultat pour l'assistance, sans partager de mots de passe, de cookies de session ni de liens privés. Des actualisations répétées apportent rarement de nouveaux éléments.
Pour interpréter un code de réponse, la référence MDN des statuts HTTP distingue réponses réussies, erreurs d'accès et erreurs serveur.
Exemple explicatif, pas des données de service en direct
Imaginons qu'un fournisseur publie huit incidents dans le mois. Sept sont courts et résolus ; le dernier a commencé il y a cinq jours et continue. Une liste limitée aux événements les plus récents pourrait le masquer. Notre liste des incidents en cours le conserve, quelle que soit son ancienneté. Le graphique compte les événements selon leur date de début, et non les personnes touchées, les heures de panne ou les signalements. Huit événements ne permettent pas de déduire une disponibilité de 99 % ou 99,9 % : il faut définir le service, la période observée et la durée d'indisponibilité mesurée. Un jour vide signifie seulement qu'aucun début d'incident n'a été trouvé dans les données disponibles.
Une source officielle indique les problèmes reconnus par le fournisseur. Un test de site indique si une URL publique a répondu à une requête externe. Nous séparons ces deux signaux : une page d'accueil peut fonctionner pendant un incident de connexion, et une protection de sécurité peut bloquer notre test alors que l'application fonctionne pour vous.
Le flux du fournisseur indique que le service est opérationnel. Un compte, une fonctionnalité ou une région peut pourtant rencontrer un problème.
Si cela ne fonctionne toujours pas pour vous, essayez un autre réseau et un autre appareil avant de modifier vos paramètres.
Le fournisseur signale des performances réduites, comme des requêtes plus lentes ou des erreurs intermittentes.
Consultez le composant touché et les notes de l’incident. Évitez de soumettre plusieurs fois un paiement ou une autre demande importante.
Une partie du service est signalée comme indisponible. D’autres composants peuvent encore fonctionner.
Vérifiez si le composant touché correspond à la fonctionnalité dont vous avez besoin, puis suivez les mises à jour du fournisseur.
Le flux signale une panne majeure du service ou des composants couverts, pas nécessairement de tous les produits de l’entreprise.
Utilisez une solution de remplacement si votre tâche est urgente. Consultez l’incident officiel pour suivre le rétablissement.
Le fournisseur a indiqué qu’un service ou un composant est en maintenance.
Consultez l’avis de maintenance pour connaître son périmètre et ses horaires. L’heure de fin prévue ne garantit pas le rétablissement.
Un incident actif est signalé, mais le flux disponible ne précise pas forcément toute sa gravité.
Ouvrez l’incident officiel pour connaître les fonctionnalités touchées et les recommandations du fournisseur.
Le flux d’incidents connecté ne contient aucun incident actif. Cela ne signifie pas que toutes les fonctionnalités ont été testées avec succès.
Comparez le résultat à la fonctionnalité qui échoue. Un nouveau problème n’a peut-être pas encore été reconnu.
Nous n’avons pas pu vérifier le flux, ou celui-ci ne fournit pas assez d’informations pour déterminer l’état du service.
Ouvrez la page d’état officielle et réessayez d’actualiser plus tard. Des données indisponibles ne prouvent ni une panne ni un bon fonctionnement.
Essayez un autre appareil sur le même Wi-Fi. Si les deux échouent, consultez les pannes locales de votre fournisseur d’accès. Un VPN, un réglage DNS ou une restriction réseau peut aussi expliquer la différence ; cela ne prouve pas à lui seul une panne du routeur.
Cherchez le composant correspondant : authentification, messagerie ou téléchargements, par exemple. Une page d’accueil accessible ne confirme pas leur fonctionnement. Notez l’erreur et consultez l’incident du fournisseur avant de multiplier les tentatives.
Essayez une fenêtre privée ou un autre navigateur. Les extensions, les données du navigateur ou la version de l’application peuvent être en cause. Enregistrez vos travaux non envoyés avant d’effacer des données ; supprimer les cookies peut vous déconnecter.
Consultez les incidents officiels concernant la fonctionnalité et la région touchées. Pour une connexion fixe ou mobile, utilisez le vérificateur du fournisseur associé à votre adresse. Plusieurs échecs constituent des indices utiles, mais ne prouvent pas une panne mondiale.
Avant de contacter l’assistance, notez l’heure, la fonctionnalité, le réseau et l’erreur exacte. Partagez un lien public d’état ou un rapport téléchargé, jamais un mot de passe ou un lien privé de compte.
La barre compte les composants renvoyés par le fournisseur, comme les API ou les régions. Elle ne mesure ni les clients touchés, ni le trafic, ni la disponibilité dans le temps. De nombreux composants peuvent fonctionner alors que celui que vous utilisez rencontre un problème.
Lorsqu’un historique est disponible, le graphique regroupe les incidents reçus selon leur date de début sur les 30 derniers jours UTC. Un incident de plusieurs jours ne devient pas un nouvel incident chaque jour. Un zéro ou un historique manquant ne prouve pas un fonctionnement ininterrompu.
La vue d’ensemble compte des signaux de services, pas des signalements de visiteurs. Des produits liés peuvent partager le même incident : ne les additionnez pas comme des pannes indépendantes. Les flux inconnus restent séparés des services sans problème signalé.
La date de récupération indique quand ClockTools a obtenu une réponse valide de la source. La date de mise à jour du fournisseur vient de cette source, lorsqu’elle est disponible. Elle n’est pas forcément celle du début ou de la résolution d’un incident. Une date ancienne ne prouve pas à elle seule une panne.
Les flux officiels sont actualisés environ toutes les deux minutes tant que la page est visible et l’actualisation automatique activée. Une réponse d’état valide peut être réutilisée pendant deux minutes, et une réponse d’historique séparée pendant cinq minutes. Actualiser peut donc afficher les mêmes dates. Une vérification de site est ponctuelle, pas une surveillance continue.
Un fournisseur peut publier un incident après que les utilisateurs l’ont remarqué. Si une source ne peut pas être vérifiée, nous indiquons des données indisponibles au lieu d’annoncer que tout va bien. Comparez vos symptômes, le lieu de vérification et la source officielle avant d’évaluer l’étendue du problème.
Nous consultons les sources publiques de services d'IA, d'applications collaboratives, de plateformes de jeux et d'infrastructures cloud. Google Workspace et Google Cloud fournissent des flux d'incidents, pas la preuve que chaque compte fonctionne. Un incident Codex n'est pas automatiquement un incident ChatGPT. Les filtres de composants séparent les résultats ; les données indisponibles ou impossibles à attribuer sont signalées clairement.
Les sources officielles ne nécessitent ni votre compte ni une clé API personnelle. Les adresses de sites sont envoyées à notre serveur pour le test externe ; seules les adresses HTTP et HTTPS publiques sont acceptées. Utilisez des liens publics ordinaires, jamais des tableaux de bord privés ou des URL contenant des secrets. Cet outil ne conserve pas votre historique de recherche. Les réponses publiques des fournisseurs sont brièvement mises en cache pour limiter les requêtes répétées.
La liste d'incidents contient uniquement les éléments renvoyés par la source officielle. La durée de conservation varie, et certaines interfaces connectées ne fournissent aucun historique. L'absence d'incidents ne devient pas une promesse de disponibilité à 100 %. Nous n'inventons ni signalements de visiteurs ni estimations du nombre de personnes touchées. Cette page est indépendante de Downdetector et des services répertoriés.
Une panne Internet est souvent locale. Choisissez Verizon, Spectrum ou Virgin Media pour accéder à l’outil du fournisseur lié à votre secteur ou à votre compte. Pour Facebook, comparez la vérification du site à la fonction qui ne marche pas sur votre appareil. Roblox propose un flux officiel ; Steam fournit un signal plus limité via son API publique. Ces sources ne mesurent pas toutes les pannes de la même manière.
Vous pouvez demander un test ponctuel de tout site HTTP ou HTTPS public, même absent du répertoire officiel. Les adresses privées, les ports inhabituels et les URL contenant des identifiants sont refusés. Les pare-feu et protections antibot peuvent empêcher un résultat concluant.
Les sources officielles s'actualisent toutes les deux minutes tant que la page est ouverte, avec un cache partagé de courte durée. Les annonces peuvent arriver après le début d'un incident. L'heure de récupération et l'heure de mise à jour du fournisseur sont différentes ; aucune ne garantit le fonctionnement de toutes les régions ou de tous les comptes.
Oui, recherchez Instagram pour tester son site public. Nous n'avons pas de source officielle vérifiée couvrant toute l'application grand public. Une page qui répond ne confirme donc pas le fonctionnement des Reels, des messages privés ou de la connexion.
Non. Une réponse 403 signifie généralement que le serveur refuse la requête ; une réponse 404 indique que cette page précise est introuvable. Dans les deux cas, le serveur répond. Même un délai dépassé ou une réponse 5xx depuis un seul lieu nécessite davantage de preuves avant de parler de panne mondiale.
Oui. Aucun compte, aucune installation ni clé API personnelle n'est nécessaire. ClockTools consulte des sources publiques et effectue des tests de sites limités. Il n'accède pas à vos comptes privés et n'utilise pas de requêtes d'IA payantes pour déterminer l'état.
Non. Les résultats reposent sur les flux des fournisseurs et des vérifications individuelles de sites, pas sur des signalements participatifs. Nous n’affichons ni totaux communautaires, ni estimations d’utilisateurs touchés, ni carte participative des pannes. ClockTools est indépendant de Downdetector.
Seul le fournisseur peut communiquer une information de référence sur le rétablissement. Suivez l’incident ou l’avis de maintenance lié. Nous n’inventons pas d’heure de retour et ne présentons pas une fin de maintenance prévue comme une garantie.