90 jours de statut. Une barre par jour et par composant.
Chaque minute, l'instance note le verdict que publie GET /api/v1/status sur le travail qu'elle mène en arrière-plan. Chaque barre est une journée, de la couleur de son pire moment.
En ce moment
Opérationnels : 4 sur 4 Non mesuré pendant les travaux, mesuré de nouveau dès qu'ils se terminent. Mesuré au plus 30 s avant .
Les 90 derniers jours
Jours UTC- Opérationnel
- Dégradé
- En panne
- Maintenance
- Aucune donnée
Le métronome de l'instance : il lance chaque tâche de fond à son heure.
100 %disponibilité
Son signal de vie, et chacune des tâches qu'il lance : le décompte du trafic sortant, la vérification des domaines personnalisés, la rétention, le vidage de la corbeille, la réconciliation du stockage et le relevé de cet historique.
Vos envois et vos liens ne passent pas par lui. Ce qui s'arrête avec lui : le trafic sortant n'est plus compté, la rétention et la corbeille attendent, les quotas ne sont plus recalculés. C'est le seul composant dont l'arrêt fait passer le verdict en « En panne ».
« Dégradé » quand une tâche est en retard ou que sa dernière exécution a échoué. « En panne » quand son signal de vie se tait depuis 3 minutes, ce qui est aussi la façon dont un trou de cet historique est compté.
Le travail mis en file après un envoi, comme la compression des vidéos et des sons.
100 %disponibilité
L'attente des tâches en file, là où l'instance peut la compter, et les tâches qui ont épuisé leurs essais.
Vos envois sont acceptés et servis comme d'habitude. Une vidéo ou un son reste servi dans son format d'origine, à la même URL, le temps que sa version compressée arrive.
« Dégradé » quand la tâche la plus ancienne attend depuis trop longtemps, qu'un processus a lâché une tâche, ou que trop de tâches ont épuisé leurs essais en une journée. « En panne » seulement quand l'instance n'a pas pu se mesurer.
Les vidéos et les sons qui attendent leur version compressée.
100 %disponibilité
Les fichiers encore en traitement plus de 60 minutes après leur envoi, sans plus rien en file pour les terminer.
Le fichier d'origine reste servi à la même URL : vos joueurs le voient ou l'entendent, simplement plus lourd que prévu.
« Dégradé » dès qu'un fichier est encore en traitement 60 minutes après son envoi sans plus rien en file pour lui. « En panne » seulement quand l'instance n'a pas pu se mesurer.
L'effacement des fichiers que vous avez supprimés.
100 %disponibilité
Un média supprimé passe 7 jours dans la corbeille, puis ses fichiers sont effacés. Ce composant vérifie que l'effacement suit le rythme.
Rien ne change de votre côté : votre quota compte déjà cet espace comme libéré. Le retard ne concerne que le disque de l'instance.
« Dégradé » quand la corbeille doit effacer plus qu'une nuit n'en efface. « En panne » seulement quand l'instance n'a pas pu se mesurer.
Lecture du trafic sortant
Le décompte des octets livrés à vos joueurs.
Rien n'a été relevé pour lui ici : il n'y a rien à tracer.
Relevé chaque minute depuis le 29 oct. 2026. Une barre est un jour UTC, de la couleur de son pire état.
La disponibilité est la part des minutes mesurées passées en état opérationnel : une minute dégradée ou en panne compte contre elle, une minute que personne n'a mesurée ou une minute de maintenance ne compte ni pour ni contre.
Une fenêtre de maintenance déclarée est tracée dans sa propre couleur, jamais comme un incident : le travail en arrière-plan est mis en pause exprès pendant sa durée, et reprend seul ensuite.
Le relevé tourne sur le planificateur. Tant que celui-ci est arrêté, rien ne peut être noté, et ce silence compte comme une panne du planificateur, sauf si une fenêtre de maintenance déclarée le couvre.
Ce que cette page ne sonde pas : l'API d'envoi, la livraison des fichiers, le tableau de bord et son fil en direct ne sont pas vérifiés de l'extérieur. Si cette page s'affiche, le serveur qui la sert répond.
Sachez-le avant vos joueurs. Avec votre propre sonde.
-
Opérationnel "ok"
Tout ce qui tourne en arrière-plan suit le rythme.
-
Dégradé "degraded"
Quelque chose en arrière-plan prend du retard. Les envois et la diffusion n'en dépendent pas.
-
En panne "down"
Le planificateur est arrêté, ou l'instance n'a pas pu se mesurer.
Dans data.health.components, scheduler, queue, processing, sweep et egress portent chacun l'un de ces trois mêmes états, sans nom de file, compteur ni message d'erreur. Ce que l'instance ne sait pas mesurer est absent, jamais affiché "ok".
Votre supervision peut interroger l'adresse que cette page consulte elle-même, sans clé d'API. Pointez-la sur cette adresse JSON plutôt que sur cette page : c'est elle qui porte le verdict.
Alertez sur data.health.state
La réponse reste HTTP 200 avec "status": "ok" quel que soit l'état : ce code dit que la requête a réussi, pas que tout va bien.
Une sonde toutes les 30 s suffit
Le verdict est recalculé au plus toutes les 30 secondes. Interroger plus souvent renvoie la même réponse.
{ "state": "ok", "components": { "scheduler": "ok", "queue": "ok", "processing": "ok", "sweep": "ok" } }
# Lire le verdict, sans clé curl -s https://aperture-app.preview.moncompanion.cloud/api/v1/status \ | jq -r '.data.health.state' # ok, degraded ou down : alertez sur tout sauf ok state=$(curl -s https://aperture-app.preview.moncompanion.cloud/api/v1/status \ | jq -r '.data.health.state') [ "$state" = "ok" ] || echo "Aperture : $state"
-- Au démarrage de la ressource : prévenir la console -- si Aperture ne suit plus le rythme PerformHttpRequest('https://aperture-app.preview.moncompanion.cloud/api/v1/status', function(code, body) if code ~= 200 then return end local state = json.decode(body).data.health.state if state ~= 'ok' then print(('[aperture] statut : %s'):format(state)) end end, 'GET')
Un souci que cette page ne montre pas ?
Gardez l'en-tête X-Request-Id de la réponse en cause : il désigne la requête exacte dans les journaux de l'instance.