Clustraly
Analytics, heatmap & tableau de bord

Endpoints de health-check et uptime : un signal fiable de l'état de votre site, à tout instant

Endpoints de health-check / uptime une fonctionnalité du module Analytics, heatmap & tableau de bord de Clustraly. Deux routes publiques, /health et /health/db, qui exposent l'état du site (base, stockage, version) via un code HTTP 200 ou 503.

Interrogez /health et /health/db pour connaître l'état de votre site en une requête non authentifiés, minimalistes, et conçus pour répondre même quand la base de données tombe.

Visibilité

Sachez en une requête si votre site répond

Interrogez /health et lisez immédiatement l'état global de votre site : base de données, stockage, version et horodatage, réunis dans une réponse unique. Un code 200 vous confirme que tout tourne, un 503 vous signale une dégradation sans ouvrir le moindre tableau de bord.

  • Statut global en un appel : base, stockage, version, horodatage
  • Code 200 « ok » ou 503 « degraded », sans ambiguïté
  • Endpoint /health/db dédié à la connectivité base seule
Deux sondes

Deux endpoints, chacun avec son rôle

/health vous donne la vue d'ensemble ; /health/db isole la connectivité de la base pour un diagnostic ciblé. Les deux répondent en clair 200 quand tout tourne, 503 dès qu'un maillon lâche pour que vous branchiez la bonne sonde au bon endroit.

Volontairement minimalistes et non authentifiés, ils restent joignables par n'importe quel outil, sans configuration lourde de votre côté.

  • GET /health : santé globale de l'application
  • GET /health/db : connectivité base isolée (200 ok / 503 down)
  • Réponses minimalistes, sans authentification
Résilience

Une réponse même quand la base tombe

C'est précisément quand tout se tait que vous avez besoin d'un signal. Les sondes sont dispatchées avant l'initialisation de la base de données : /health continue donc de répondre même pendant une panne c'est sa raison d'être.

La sonde base reste rapide et bornée. Elle réutilise une connexion déjà ouverte, sinon effectue un pré-check réseau puis une connexion à délai court, pour ne jamais rester suspendue.

  • Dispatch avant Database::init() : /health répond même base en panne
  • Pré-check TCP borné (~1 s), fiable y compris sous Windows
  • Connexion PDO à délai court (2 s), connexion ouverte réutilisée
Cas d'usage

Branchez vos moniteurs et vos load balancers

Ces endpoints parlent le langage universel de la supervision : un code HTTP simple. Pointez-y votre moniteur d'uptime, votre load balancer ou votre orchestrateur ils sondent /health à intervalle régulier et savent en un instant s'il faut alerter ou rediriger le trafic.

Besoin d'un diagnostic plus fin ? /health/db vous isole la santé de la base, pour distinguer une panne applicative d'une panne de connectivité.

  • Sondes régulières par un moniteur d'uptime externe
  • Health-check pour load balancer ou orchestrateur
  • Diagnostic base seule via /health/db
Garde-fous

Ouverts au monde, mais rien à révéler

Non authentifiés pour rester joignables en toutes circonstances, ces endpoints sont conçus pour ne rien laisser filtrer. En cas d'échec, ils ne divulguent jamais l'hôte, les identifiants ni la raison de la panne.

La vérification du stockage confirme que les dossiers logs, cache et storage sont accessibles en écriture et les crée s'ils manquent. Chaque réponse porte les en-têtes qui empêchent toute mise en cache parasite.

  • Aucune fuite d'hôte, d'identifiants ou de cause d'échec
  • En-têtes Cache-Control: no-store et X-Request-Id sur chaque réponse
  • checkStorage vérifie logs, cache et storage (et les crée si absents)
Pourquoi ça compte

La sonde qui parle quand tout se tait

Parce que /health est dispatché avant l'initialisation de la base, il vous répond même en pleine panne. C'est exactement le moment où vous avez besoin de savoir.

FAQ

Questions fréquentes

Faut-il s'authentifier pour appeler /health ou /health/db ?
Non. Les deux endpoints sont volontairement non authentifiés et minimalistes, pour rester joignables par vos outils de supervision en toutes circonstances. Ils ne renvoient qu'un statut, jamais de données sensibles.
Que signifient les codes 200 et 503 ?
Sur /health, 200 indique un statut « ok » global (base, stockage, version, horodatage) et 503 une dégradation. Sur /health/db, 200 signale une base joignable et 503 une base « down ».
Comment /health répond-il si la base de données est tombée ?
Les sondes sont dispatchées avant l'initialisation de la base. /health continue donc de répondre pendant une panne c'est sa raison d'être. La sonde base reste bornée par un pré-check réseau (~1 s) puis une connexion à délai court (2 s).
Ces endpoints exposent-ils des informations sur mon infrastructure ?
Non. En cas d'échec, ils ne divulguent jamais l'hôte, les identifiants ni la cause de la panne. Les réponses portent les en-têtes Cache-Control: no-store et X-Request-Id.
Prêt à commencer ?

Surveillez votre site sans y penser

Branchez /health et /health/db à vos outils de supervision et laissez-les veiller. Vous gardez un signal fiable de l'état de votre site même quand la base flanche sans jamais exposer la moindre information sensible.