HTTP/HTTPS

Présentation

Le monitor HTTP/HTTPS vérifie la disponibilité d’un service web en envoyant une requête HTTP à l’URL spécifiée et en analysant la réponse. C’est le type de monitor le plus utilisé.

Paramètres de base

Paramètre	Description	Valeur par défaut
URL	Adresse complète du service (https://...)	—
Méthode	GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS	GET
Intervalle	Fréquence de vérification	le plus court permis par le plan
Code(s) attendu(s)	Code(s) HTTP considéré(s) comme succès, ex. 200 ou une plage 200-299	200-299
Régions	Régions de vérification	une, la moins chère du plan
Essais (retries)	Échecs consécutifs tolérés avant de marquer le monitor down	1 (soit 2 échecs)

Chaque vérification dispose d’un budget fixe de 5 secondes — connexion, réponse et, en HTTPS, la lecture du certificat s’y déroulent. Il n’y a pas de réglage de timeout par monitor : une cible qui n’a pas répondu en 5 s compte comme un échec.

Paramètres avancés

Authentification

Un point d’accès protégé a son propre bloc : Basic auth, jeton Bearer, clé d’API (en-tête ou paramètre d’URL), cookie de session, OAuth2 client credentials, ou certificat client (mTLS). Chaque secret est chiffré au repos et masqué à la lecture — voir Authentification.

Headers personnalisés

Ajoutez des en-têtes HTTP à chaque requête de vérification, en complément (ou à la place) du bloc d’authentification :

X-Tenant: acme
Content-Type: application/json
Accept: application/json

Body de requête

Pour les méthodes POST ou PUT, définissez un body JSON envoyé à chaque vérification :

{
  "health": true
}

Cas d’usage : vérifier qu’un endpoint d’API répond correctement à une requête POST (ex : endpoint de health check qui attend un body spécifique).

Vérification du contenu : mot-clé ou requête JSON

En plus du code HTTP, un monitor HTTP peut valider le contenu de la réponse. Dans la modale de création (étape 1, juste sous l’URL) et dans le panneau d’édition, le sélecteur Vérification du contenu propose trois modes :

Mode	Ce qu’il fait
Code HTTP seulement	Par défaut — seuls les codes HTTP acceptés sont vérifiés.
Mot-clé	Le check échoue si le texte n’est pas trouvé dans le body (ou, en mode inversé, s’il est trouvé).
Requête JSON	La réponse est parsée en JSON, un chemin est résolu puis comparé à une valeur attendue.

Mot-clé et requête JSON sont exclusifs : un monitor utilise l’un ou l’autre. Le bouton Tester évalue la vérification du contenu avec le code HTTP, la méthode, les headers et les identifiants : le résultat affiché est exactement celui que produiront les vrais checks — un échec de contenu indique la raison (ex. Keyword 'operational' not found in response body).

Mot-clé

Champ	Description
Mot-clé	Texte recherché dans le body brut de la réponse — HTML ou JSON. Sensible à la casse.
Doit être absent	Inverse la vérification : elle échoue si le mot-clé est trouvé (page de maintenance servie en 200).

Exemples d’utilisation :

• Vérifier que votre page d’accueil contient Bienvenue (et pas une page d’erreur avec un 200).
• Vérifier qu’une API retourne "status":"operational".
• Détecter les pages de maintenance servies avec un code 200.

Quand utiliser le keyword check ?

Un serveur peut retourner un code 200 tout en servant une page d’erreur (load balancer, CDN, page de maintenance). Le keyword check détecte ces faux positifs que le code HTTP seul ne peut pas attraper.

Requête JSON

Champ	Description
Chemin JSON	Notation pointée depuis la racine du document : component.status, data.items.0.name. Le préfixe $. est accepté. $ seul désigne le body brut.
Opérateur	==, !=, contains, >, <, >=, <=
Valeur attendue	Comparée à la valeur résolue sous forme de chaînes (nombres et booléens sont convertis : true, 42). Les opérateurs numériques parsent les deux côtés.

Le check échoue si le body n’est pas du JSON valide, si le chemin ne résout rien, ou si la comparaison est fausse. $ saute le parsing JSON et compare tout le body (sans espaces de bord) — pratique pour les endpoints de santé en texte brut qui répondent OK ou pong.

Exemple — un endpoint de composant Statuspage comme https://public-cloud.status-ovhcloud.com/api/v2/components/8x32jhcpqq1m.json retourne :

{ "page": { "...": "..." }, "component": { "name": "GRA1", "status": "operational" } }

Chemin JSON	Opérateur	Valeur attendue	Résultat
component.status	==	operational	✅ réussi
component.status	!=	operational	❌ échoue dès que le composant est dégradé/down
$	contains	"status":"operational"	✅ réussi (body brut)

Certificat SSL / TLS

Pour une cible https://, OKStatus lit le certificat à chaque vérification et enregistre le nombre de jours restants avant expiration.

• Un certificat expiré ou invalide fait échouer la vérification.
• Les alertes d’expiration sont disponibles à partir du plan Pro, à 30, 14, 7, 3 et 1 jour avant l’expiration du certificat — une alerte par seuil, pas une par vérification. L’expiration du nom de domaine est surveillée de la même façon, à 60, 30, 14 et 7 jours.
• Ce sont deux types d’alerte distincts : un canal peut recevoir les pannes sans les alertes de certificat (ou l’inverse).

Cochez Ignorer la validation du certificat TLS sur le monitor pour accepter un certificat auto-signé ou expiré — pour un environnement de recette que vous assumez.

Redirections

Un monitor suit les redirections par défaut, jusqu’à 5 sauts, et chaque saut est revérifié avec les mêmes règles de sécurité que l’URL d’origine. Le code classifié est celui de la fin de la chaîne.

Désactivez Suivre les redirections pour vérifier l’URL exactement telle que saisie. Le monitor demande alors comment traiter un 3xx absent de vos codes acceptés :

Réglage pour un 3xx	Résultat
Dégradé (par défaut)	Le serveur a répondu — c’est un écart de configuration, pas une panne. Orange, personne n’est réveillé.
Down	Strict : toute redirection inattendue est traitée comme une panne.

Les 4xx, 5xx et les cibles injoignables sont toujours down une fois la fenêtre de réessai épuisée, quel que soit ce réglage. Si vous voulez que la redirection compte comme un succès, ajoutez plutôt son code (ex. 301) aux codes acceptés — le bouton Tester le propose justement quand il en rencontre une.

Métriques collectées

Chaque check HTTP enregistre :

Métrique	Description
Statut	up, degraded ou down
Code HTTP	Code de réponse (200, 404, 503…)
Latence	Temps de réponse total en ms
Région	Région d’où le check a été effectué
Horodatage	Date et heure exactes du check

Ces métriques alimentent les graphiques du dashboard, les rapports PDF mensuels et les calculs d’uptime affichés sur vos pages de statut.