Choisir un produit
Hébergement webSites web et WordPress avec un forfait à prix fixeCloudDéployez applications, API et bases de données depuis Git ou DockerAI BuilderCréez et modifiez des sites et des applications avec l’IAÀ ajouter à tout projet
Domaines et e-mailBases de donnéesWordPress géréExécution d’agentsMigrationsDéveloppeurs
Tout sur l’IADéveloppeursMCP pour assistants IADocumentationSécuritéStatutHostingsurge
TarifsSe connecterStatut
Chaque composant ci-dessous a réussi sa dernière vérification. La plateforme se vérifie elle-même chaque minute et cette page n’affiche que ce que ces vérifications ont enregistré.
Chaque barre correspond à un jour UTC : la part des vérifications de ce jour qui ont réussi. Survolez un jour pour voir les chiffres.
GET /api/health répond 200 avec {"status":"ok"}.
Opérationnel
GET /api/v1/me sans identifiants reçoit une réponse 401 de l’API : elle est en ligne et refuse les appels anonymes.
Opérationnel
POST /mcp en tant que client MCP sans identifiants reçoit une réponse 401 : le serveur est en ligne et demande OAuth.
Opérationnel
Aucun déploiement n’a attendu dans la file plus de 20 minutes ni n’est en build depuis plus de 90 minutes.
Opérationnel
La cible CNAME vers laquelle les clients font pointer leurs domaines se résout vers notre ingress, et le proxy edge établit TLS et répond en HTTP.
Opérationnel
Le serveur de boîtes mail répond en HTTPS et son port de soumission SMTP salue avec 220.
Opérationnel
Le point de terminaison web et API de Postal répond en HTTPS et son port SMTP salue avec 220.
Opérationnel
Ouverts automatiquement après 3 vérifications échouées d’affilée et fermés après 3 vérifications réussies d’affilée. Les 90 derniers jours, du plus récent au plus ancien.
Aucun incident depuis le début des mesures, le 24 sept. 2026.
Les règles derrière chaque chiffre ci-dessus. Rien sur cette page n’est saisi à la main, à part les notes de l’équipe sur les incidents.
Un vérificateur du service API de la plateforme appelle chaque composant par le même chemin qu’une requête client — DNS public, proxy edge, puis le service — et enregistre chaque résultat dans la base de données de la plateforme.
Trois vérifications échouées d’affilée ouvrent un incident ; trois vérifications réussies d’affilée le ferment. Il commence à la première vérification échouée et se termine à la première réussie.
Les vérifications réussies divisées par les vérifications enregistrées sur la période, arrondi à la baisse à deux décimales — un seul échec ne s’affiche jamais comme 100 %. Les jours sans vérification apparaissent comme « aucune donnée », pas comme disponibles.
Le vérificateur s’exécute dans le service API. Tant que ce service est en panne, rien n’est enregistré : ces minutes apparaissent comme des données manquantes plutôt que comme une indisponibilité, et cette page ne peut pas se charger. Les vérifications partent du propre réseau de la plateforme, pas d’autres régions.
Les mêmes données en JSON, consultables librement sans compte : GET /api/v1/status
La documentation indique où se trouve chaque fonctionnalité dans le tableau de bord et la CLI ; la page Développeurs couvre l’API, et /api/v1/openapi.json documente chaque point de terminaison, y compris ce document d’état.
Ces chiffres sont des mesures, pas une promesse : aucune garantie de disponibilité ni aucun niveau de service (SLA) n’est proposé pendant la période de développement actif. Conditions d’utilisation