La surveillance par mot-clé qui détecte les pages qui se chargent mais sont cassées.

Une vérification de contenu qui s'appuie sur votre sonde de disponibilité : elle lit le contenu de réponse de la page à chaque vérification et échoue si le texte requis est absent ou si le texte interdit est présent. Une page peut se charger parfaitement et être cassée quand même — c'est précisément ce qu'une vérification par mot-clé détecte.

À chaque vérification, Uptimia récupère la page et recherche dans le contenu de réponse le texte que vous avez défini : les mots « doit contenir », qui doivent être présents, et « ne doit pas contenir », qui doivent être absents. Une règle en échec est relue depuis d'autres régions avant qu'un incident ne s'ouvre.

« Doit exister » échoue quand le texte requis a disparu — un « Add to cart » manquant, un prix, un message de succès. « Ne doit pas exister » échoue quand un texte interdit apparaît — une erreur de base de données, une trace de pile, un bandeau « De retour bientôt ». Utilisez autant de règles de chaque type que nécessaire.

Une vérification par mot-clé lit le HTML brut renvoyé par le serveur, elle ne voit donc pas le texte qu'un navigateur dessine plus tard via JavaScript. Pour les applications monopages et autre contenu rendu côté client, une sonde de transaction charge la page dans un vrai navigateur et vérifie le texte après son rendu.

Non — elle fait partie d'une sonde HTTP/disponibilité. Vous ajoutez des règles de mot-clé à une sonde de site web que vous avez déjà, et elles s'exécutent selon le même calendrier et depuis les mêmes emplacements, sans requête supplémentaire.

Oui. Une sonde peut porter plusieurs règles à la fois — exigez quelques chaînes et interdisez-en d'autres — et la vérification échoue dès qu'une seule règle échoue.

Oui. La règle recherche le texte n'importe où dans le contenu de réponse, vous pouvez donc exiger la présence d'un champ ou d'une valeur, ou interdire un message d'erreur, sur un point de terminaison JSON aussi facilement que sur une page HTML.

L'incident enregistre l'échec signalé par la vérification, les règles de mot-clé de la sonde, et le contenu de réponse réellement lu — vous regardez donc la page telle qu'elle a échoué, pas une version qui fonctionne quand vous rechargez.

Un échec de mot-clé est relu depuis plusieurs régions avant toute alerte, si bien qu'un seul rendu partiel ne vous alerte jamais. Le rétablissement est sûr par défaut — une seule lecture propre clôture l'incident.

Oui. Les vérifications par mot-clé font partie de chaque sonde de disponibilité sur chaque forfait, jamais une option payante. Le forfait gratuit inclut une sonde avec règles de mot-clé à des intervalles de 5 minutes, sans carte bancaire ; Basic porte cela à 10 sondes, Professional à 100 avec des intervalles de 30 secondes, et les forfaits vont jusqu'à 1 000. L'essai de 30 jours débloque tout, avec de la place pour 500 sondes.

Pas avec les paramètres par défaut, et c'est délibéré. Une lecture en échec est revérifiée depuis d'autres régions, et par défaut trois doivent concorder avant qu'un incident ne s'ouvre — c'est précisément ce qui empêche un seul chargement lent ou partiellement rendu de réveiller qui que ce soit. Un échec véritablement spécifique à une région, comme une périphérie CDN servant une erreur mise en cache, ne sera peut-être pas reproduit ailleurs ; il apparaîtra alors dans le journal du point de contrôle concerné, sans ouvrir d'incident. Si c'est précisément l'échec qui vous préoccupe le plus, réglez la confirmation de panne de la sonde sur une seule région : le premier point de contrôle qui lit le mauvais contenu vous alertera alors.