Méthode de test

Plusieurs signaux, une seule réponse

Pour chaque service, nous recueillons jusqu'à quatre signaux indépendants. Chacun peut donner l'alerte, et le plus grave encore récent détermine le statut affiché. Une source muette ou obsolète est ignorée plutôt que suivie aveuglément.

Des requêtes de test envoyées par nos soins

Dès que nous disposons d'un accès API, un robot envoie un court prompt en streaming directement à l'API du fournisseur toutes les une à deux minutes, et mesure le délai de réception du premier token. Une tentative infructueuse est rejouée deux fois à vingt secondes d'intervalle avant d'être comptabilisée. Les erreurs de limite de débit (rate limit) et les fautes de configuration de notre côté sont écartées afin de ne pas faire passer un service sain pour un service défaillant.

• En panne les trois derniers tests consécutifs ont échoué
• Panne partielle la moitié ou plus des tests des dix dernières minutes ont échoué
• Ralentissements au moins un test sur cinq a échoué, ou le premier token met plus de 3 secondes et trois fois plus de temps que la médiane des dernières 24 heures

La page de statut officielle du fournisseur

Nous interrogeons les pages de statut officielles chaque minute en ne retenant que les éléments pertinents pour le service concerné — les composants ChatGPT pour ChatGPT, pas l'ensemble de l'infrastructure d'OpenAI. Si une page n'a pas été mise à jour depuis quinze minutes, nous l'ignorons : une page bloquée ne doit pas pouvoir maintenir un service au vert, ni au rouge.

Le trafic réel sur OpenRouter

OpenRouter publie le taux de réussite des requêtes pour chaque modèle chez chaque fournisseur. Nous surveillons les modèles d'un fournisseur hébergés sur ses propres endpoints. Dès qu'au moins deux d'entre eux, représentant au moins la moitié du groupe, tombent sous les 80 % de succès sur 30 minutes tout en étant dix points sous leur moyenne quotidienne, le service passe en « Ralentissements » ; sous les 50 % en moyenne, en « Panne partielle ».

Si trois fournisseurs ou plus chutent en même temps, le point commun est OpenRouter lui-même : ce signal est alors temporairement écarté pour tous.

Les signalements des utilisateurs

Chaque page de service comporte un bouton « J'ai un problème ». Dix signalements ou plus en quinze minutes, à un rythme quatre fois supérieur à la normale pour ce service, le font passer en « Ralentissements ». Les signalements seuls ne peuvent jamais faire basculer un service en « En panne », et chaque visiteur n'est comptabilisé qu'une fois par service par demi-heure, avec un plafond par heure.

Éviter les fausses alertes

Le diagnostic est recalculé toutes les 30 secondes. Pour repasser à « Opérationnel », un service doit rester stable pendant trois minutes complètes, évitant ainsi qu'une API instable n'oscille constamment sur cette page.

Comprendre les barres de couleur

La frise de 24 heures comprend 48 barres d’une demi-heure chacune ; la frise de 30 jours affiche une barre par jour. Chaque barre prend la couleur de l’état le plus critique observé sur la période. Le gris signifie que nous n’avions aucune donnée à ce moment-là, et non que tout fonctionnait normalement.

Ce que nous ne pouvons pas voir

Nos robots tournent dans un centre de données en Europe : une panne limitée à un pays, un réseau mobile ou un réseau d’entreprise peut donc nous échapper. Nous n’avons pas non plus accès aux limites ou à la facturation de votre compte. De plus, certains services, comme Midjourney, n’ont ni API publique ni page de statut ; pour ceux-là, nous dépendons entièrement des signalements des utilisateurs.

D’où viennent ces chiffres

isAIlive est un projet frère de llmlive.ai, qui assure la surveillance technique ; les deux sites exploitent les mêmes mesures. Ce site a un seul objectif : vous indiquer si l’outil dont vous avez besoin fonctionne en ce moment même.

llmlive.ai →

Signification des états

• Opérationnel Aucune source ne signale d’anomalie.
• Maintenance Le fournisseur a annoncé une intervention planifiée.
• Ralentissements Erreurs ou lenteurs constatées, mais la majorité des requêtes aboutit.
• Panne partielle Une part importante des requêtes ou toute une fonctionnalité est en échec.
• En panne Le service est inaccessible pour la majorité des utilisateurs.
• Aucune donnée Aucune donnée récente disponible, toutes sources confondues.