Check HTTP(S)

Ce qu’il vérifie

Un monitor HTTP(S) interroge l’URL à son intervalle depuis chacune de ses régions. Il vérifie le code de statut et, le cas échéant, un mot-clé ou une expression régulière dans le corps, puis il enregistre le temps de réponse. Des sous-checks facultatifs pour le certificat, les en-têtes de sécurité et l’hygiène DNS tournent dans le même monitor : un hôte en panne ouvre donc un seul incident, et non quatre.

À utiliser quand

• Un service expose un endpoint HTTP qui répond quand le service est sain : un chemin de health check, une page d’accueil ou une route d’API.
• La réponse demande un check du contenu, pas seulement de la joignabilité : un code de statut, une chaîne dans le corps ou un motif.
• Le certificat, la posture des en-têtes et les enregistrements SPF, DMARC et CAA du domaine doivent être vérifiés dans le même monitor, plutôt que dans 3 monitors supplémentaires.

Il n’exécute aucun parcours dans un navigateur, ne se connecte à aucun compte et suit 5 redirections au plus. Pour un port sans HTTP, utilisez le check de port TCP. Pour un certificat qui mérite son propre incident, utilisez le check de certificat TLS.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Cible. Une URL complète avec son schéma (https:// ou http://). La sonde résout et valide l’URL et chaque saut de redirection avant de l’appeler. Elle refuse les adresses de boucle locale, privées, link-local et de métadonnées cloud, si bien que le monitor ne peut pas viser un réseau interne.

Certificat TLS

Sur une URL https, le même monitor juge le certificat qui lui est servi : le handshake, la chaîne, l’émetteur et le sujet. Le formulaire active ce sous-check pour chaque URL https.

En-têtes de sécurité

La sonde envoie une seconde requête et cherche dans sa réponse les en-têtes choisis. Seule leur présence compte. Un en-tête manquant est un constat de posture, pas une panne : la gravité par défaut est donc « dégradé ».

Hygiène DNS

La sonde lit SPF, DMARC et CAA du domaine comme de la configuration. Ces enregistrements décident si le mail du domaine est délivré et qui peut émettre des certificats pour lui. Le constat s’affiche avec le résultat et ne change jamais l’état du monitor.

Déroulement d’un check

1. Quand un check arrive à échéance, chaque région compile d’abord la regex. Une regex invalide termine le check en erreur. Chaque check expire après 10 s.
2. Le nœud résout l’hôte par son propre résolveur et confronte chaque adresse de la famille choisie aux plages bloquées. Chaque adresse reçoit ensuite sa propre requête, avec la connexion épinglée à cette adresse.
3. La sonde suit elle-même les redirections, 5 sauts au plus. Elle résout et valide à nouveau chaque saut avant de l’appeler.
4. La sonde juge d’abord le code de statut, puis le mot-clé et la regex. Elle ne lit le corps que si l’un des deux est défini, et toutes les assertions se combinent par ET.
5. Seul un check https réussi, avec le sous-check de certificat TLS actif, exécute la politique de certificat, une fois par check. Un check réussi ou dégradé ajoute la note des en-têtes et le constat d’hygiène DNS comme sous-résultats distincts.
6. La région envoie son résultat au plan de contrôle. La politique d’alerte décide si un résultat en échec ouvre un incident une fois le quorum atteint. Un résultat dégradé reste hors de l’évaluation des incidents.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Code de statut

Le statut final après les redirections, jugé par rapport à expected_status.

Temps de réponse

Le temps jusqu’à la réponse, corps compris quand il est lu, par région et par adresse (latency_ms).

Ligne de détail

Une ligne qui dit ce qui s’est passé, par exemple HTTP 200, keyword not found ou regex did not match. Elle nomme aussi un statut inattendu ou l’erreur de transport.

Couche de cause

Indique si un échec relevait du DNS de la cible (nom introuvable) ou, après une résolution réussie, de la cible elle-même. Toute autre cause est signalée comme inconnue.

Certificat

Le common name et les noms alternatifs, l’émetteur, les dates de validité avec les jours restants, et le statut de confiance.

En-têtes de sécurité

Les en-têtes demandés qui étaient présents et ceux qui manquaient.

Hygiène DNS

Les constats SPF, DMARC et CAA, par exemple une politique DMARC à none ou un enregistrement CAA absent.

Région, famille, adresse

Chaque résultat porte la région qui l’a mesuré, et un sous-résultat par famille IP et par adresse.

États et gravité

• okLe statut correspond et chaque assertion tient. Un certificat dans sa fenêtre d’avertissement conserve cet état.
• dégradéUn en-tête de sécurité manque à la gravité par défaut, ou une famille IP échoue pendant que l’autre répond.
• en panneLa requête échoue, expire ou est bloquée, ou bien le statut ou une assertion ne correspond pas. Une politique de certificat en échec (certificat expiré, handshake rejeté, émetteur ou sujet différent) et un en-tête manquant à la gravité failed comptent aussi.
• erreurLa configuration ne peut pas s’exécuter, par exemple à cause d’une regex invalide. Cet état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. La règle par défaut de l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle, avec un nombre ou un pourcentage, des checks consécutifs et une durée minimale.

Offres et limites

Intervalle minimal

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command et 10 s en Enterprise. Le formulaire web propose 30 s, 1 min, 5 min, 15 min et 1 h. Les intervalles de 15 s et 10 s ne sont accessibles que par MCP.

Régions

2 sur 6 en Free, 3 sur 6 en Pulse et les 6 à partir de Sentinel.

Monitors

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command et un quota sur mesure en Enterprise. Onze types de sonde partagent ce quota, tandis que les agents hôtes et les heartbeats ont le leur. Un pack de 50 monitors supplémentaires coûte 39 €.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

{
  "name": "Order API",
  "type": "http",
  "interval_seconds": 60,
  "config": {
    "url": "https://orders.example.com/health",
    "expected_status": 200,
    "keyword": "ok",
    "tls_cert": { "enabled": true, "warn_days": 21 },
    "security_headers": {
      "enabled": true,
      "headers": ["strict-transport-security", "content-security-policy"],
      "missing_severity": "degraded"
    },
    "dns_hygiene": { "enabled": true }
  }
}

Chaque interface, avec sa limite

Limites

• La sonde n’exécute ni parcours de navigateur ni JavaScript, et ne suit aucun flux de connexion. Elle n’envoie ni corps de requête ni cookies.
• La méthode et les en-têtes de requête se règlent par l’API ou MCP, pas dans le formulaire.
• La sonde suit 5 sauts de redirection au plus, et une chaîne plus longue fait échouer le check.
• La note des en-têtes de sécurité vérifie leur présence, pas leurs valeurs.
• La sonde refuse les cibles sur des adresses privées, de boucle locale, link-local et de métadonnées cloud.
• Toutes les régions ne sondent pas en IPv6 : choisir ipv6 restreint donc les régions utilisables.

Types de checks liés

• Check des en-têtes de sécuritéPrésence de 5 en-têtes de sécurité sur une URL, en monitor à part avec son propre historique.
• Check de certificat TLSExpiration, émetteur et sujet d’un certificat par handshake TLS direct, avec un avertissement avant l’expiration.
• Check de port TCPUn port accepte ou non les connexions, avec en option le certificat qu’il sert.
• Check d’hygiène DNSSPF, DMARC avec sa politique et CAA d’un domaine, notés comme posture et jamais comme panne.

Tous les types de checks