Les checks de santé internes passent pendant que le site est injoignable depuis l'extérieur. Cronitorex appelle vos points de terminaison depuis sa propre infrastructure, comme le ferait un utilisateur, et vous dit quand la réalité et vos dashboards se contredisent.
Un HTTP 200 avec un corps vide reste une panne. Chaque check définit à quoi ressemble une réponse saine, et tout le reste compte comme un échec.
GET https://api.example.com/health interval 60s / 30s assert status 200 · body =~ "ok" timeout 5s last result 200 in 187 ms p99 (24h) 312 ms
Les réseaux ont des ratés. Quand un check échoue avec une erreur transitoire, Cronitorex réessaie avec backoff : après 60 secondes, puis 5 minutes, puis 15 minutes. Si un retry réussit, aucune alerte n'est envoyée.
Les échecs durs sautent les étapes. Quand votre endpoint renvoie 500 ou refuse carrément les connexions, l'alerte part immédiatement, suivie d'un avis de rétablissement une fois les checks redevenus verts.
Les checks tournent toutes les 60 secondes sur Free et Pro, et toutes les 30 secondes sur Business. Le pire cas de détection est un intervalle plus le premier retry, pas le moment où quelqu'un ouvre le site par hasard.
Chaque check enregistre aussi le temps de réponse, pour que vous voyiez la semaine qui ralentit avant le jour de la panne. Les tendances vivent sur le même dashboard que vos crons et vos certificats.
Checks toutes les 60 secondes, retries avec backoff, historique du temps de réponse sur chaque check.
Checks toutes les 30 secondes, pour les endpoints où chaque minute d'indisponibilité a un coût.
Depuis l'infrastructure de Cronitorex dans l'UE, en dehors de votre réseau. Un check exécuté juste à côté de votre app rate les échecs que vos utilisateurs rencontrent réellement, comme les problèmes de DNS, de TLS ou de routage.
Non. Les retries sont internes. Vous recevez une alerte quand un échec est confirmé, et un avis de rétablissement quand les checks repassent au vert, par email, Telegram, Discord, Slack ou webhook.
Oui. Ajoutez des en-têtes personnalisés comme un jeton Authorization, choisissez la méthode HTTP et joignez un corps de requête. Les valeurs des en-têtes sont stockées chiffrées et jamais incluses dans les messages d'alerte.
Inscrivez-vous, récupérez une clé API, collez le curl dans votre cron. C'est tout.