Documentation et exemples
Quoi surveiller, et comment.
Holter surveille de deux façons. Heartbeats entrants — tes tâches nous pingent quand elles terminent, et on alerte si un ping manque à l'appel. Checks sortants — on demande ton URL, ton certificat, ton port ou ton DNS depuis l'extérieur selon un planning. Pas d'agent serveur, pas d'accès à tes serveurs. Et sur Business, les dépendances — on surveille les pages de statut des fournisseurs dont tu dépends, pour que tu apprennes leurs pannes en premier.
Heartbeats entrants
Un dead-man switch : pingue-nous en cas de succès, et on alerte si ça devient silencieux. Idéal pour les sauvegardes, workers de queue, crons, pipelines et webhooks.
1 · Crée ton heartbeat entrant
Comment Holter surveille
Nom
Alerter si aucun ping en
Ton URL de ping
Holter la génère — copie-la depuis le dashboard.
2 · Puis pingue-la avec curl depuis ta tâche
# success — at the end of the job
pg_dump … | gzip | aws s3 cp - s3://… \
&& curl -fsS "$HOLTER_URL"
# failure — alert right away
curl -fsS "$HOLTER_URL/fail"
Rate la fenêtre et Holter ouvre un incident et alerte tes canaux. Même principe pour les workers de queue (ping toutes les quelques minutes) et les crons (ajoute le curl en fin de ligne).
Tu préfères par email ? Passe le heartbeat en adresse unique (…@in.holter.sh) et fais envoyer ton app à cette adresse selon un planning. Si tes emails cessent de partir, Holter te le dit — il surveille tout le pipeline d'envoi, pas juste ton code.
Checks sortants
On atteint ton service depuis internet selon un planning — rien à installer. Idéal pour l'uptime, la santé API, SSL, domaine, DNS et TCP.
Crée un check sortant
Comment Holter surveille
Quoi vérifier
Endpoint
Statut attendu
Alerter si plus lent que
Ce que ça détecte
- ● En panne, ou mauvais code de statut
- ● Actif mais lent au-delà de ton budget de latence (dégradé)
- ● Rétabli — avec la durée de la panne
Passe en Quoi vérifier vers SSL, Domaine, DNS ou Redirection — même écran, juste une URL, sans champ supplémentaire. Les checks de certificat et de domaine te préviennent plusieurs jours avant expiration.
Astuce : dans Holter, « Quoi surveiller » configure tout ça pour toi en un clic.
Surveille ce dont tu dépends Business
Certaines pannes ne sont pas les tiennes. Quand Stripe, AWS, ton fournisseur d'auth ou ton hébergeur de base de données a un incident, ton app le ressent — et tes clients t'en tiennent responsable. Ajoute ces fournisseurs comme dépendances et Holter surveille leurs pages de statut publiques, pour que tu l'apprennes d'abord par une alerte.
Ajoute une dépendance
Fournisseur
URL de la page de statut
Ou choisis parmi 24 fournisseurs populaires qu'on sait déjà lire.
Qu'est-ce qui en dépend ?
M'alerter
Ce que ça détecte
- ● Un fournisseur — ou l'un de ses composants — signale un service dégradé
- ● Un fournisseur signale une panne totale — alerte envoyée sur tes canaux
- ● Rétabli — l'incident amont est levé
Holter lit la propre page de statut publiée de chaque fournisseur toutes les quelques minutes — il ne sonde pas leurs systèmes. Fonctionne pour toute page avec un flux de statut public (la plupart des SaaS), avec un support intégré pour AWS, Google Cloud et Azure.
Liste en option les dépendances choisies sur ta propre page de statut comme « Services amont. »
Badges de statut
Chaque page de statut publique expose un badge SVG intégrable — un aperçu en direct de votre statut ou de votre disponibilité que vous pouvez insérer dans un README, un wiki ou votre propre site. Aucune clé API, et il se met à jour tout seul.
Récupérez le snippet
URL du badge
Markdown
Variante disponibilité
Exemple en direct
- ✓ Mise à jour automatique — reflète votre statut réel en moins d’une minute
- ✓ Public et autonome — s’affiche partout où une image fonctionne
Configure-le avec ton agent de code (MCP)
Plutôt que de remplir les formulaires ci-dessus à la main, laisse ton agent faire un premier passage. Holter fait tourner un serveur MCP — connecte Claude Code, Cursor, ou tout agent compatible MCP avec un token limité à ton équipe et il lit ton repo en local, propose les monitors qu'il trouve (crons, queues, health checks, domaines), et écrit le code de heartbeat à valider.
1 · Ajoute le serveur MCP
{
"mcpServers": {
"holter": {
"type": "http",
"url": "https://app.holter.sh/api/mcp",
"headers": { "Authorization": "Bearer ${HOLTER_TOKEN}" }
}
}
}
Récupère un token limité à ton équipe depuis Réglages → MCP et configure-le comme HOLTER_TOKEN. Le token est la seule chose dont l'agent a besoin — il est limité à ton équipe Holter et ne donne aucun accès à ton code, tes serveurs ou ton cloud.
2 · Puis demande simplement
"Set up Holter monitoring for this repo —
read holter.sh/use and follow it."
- ✓ Il lit ta base de code en local — Holter ne reçoit jamais ton code source
- ✓ Il propose les monitors et le code de heartbeat ; tu revois et appliques chaque changement
- ✓ Il travaille via le token, jamais tes clés — il ne peut pas toucher à tes systèmes
Checklist de monitoring pour la production
Chaque ligne se configure en 3 minutes — ou en un clic depuis « Quoi surveiller » dans l'app.
-
Page d'accueil / app principale répond
Check HTTP sortant, attend 200
-
Endpoint API ou santé répond
Check HTTP sortant sur /health, optionnellement vérifie une chaîne dans le contenu
-
Temps de réponse dans le budget
Ajoute un budget de latence « alerter si plus lent que »
-
Redirection HTTP vers HTTPS
Check de redirection sortant
-
Certificat TLS pas proche de l'expiration
Check SSL sortant
-
Domaine pas sur le point d'expirer
Check de domaine sortant (RDAP)
-
DNS toujours résolu
Check DNS sortant
-
Sauvegarde nocturne terminée
Heartbeat entrant depuis le script de sauvegarde
-
Workers de queue actifs et à jour
Heartbeat entrant depuis un ping planifié du worker
-
Tâches planifiées / crons exécutées
Heartbeat entrant à la fin de chaque cron
-
Pipelines critiques (ETL, facturation)
Heartbeat entrant en cas de succès, /fail en cas d'erreur
-
Emails transactionnels toujours envoyés
Monitor email entrant — ton app envoie un email à une adresse unique selon un planning
-
Port base de données / cache accessible
Check TCP sortant (host:port public)
-
Webhooks tiers toujours déclenchés
Heartbeat entrant depuis ton gestionnaire de webhook
-
Page de statut publiée
Active-en une pour que les clients se renseignent seuls pendant les incidents
-
Statut du fournisseur de paiement
Ajoute Stripe (ou ton processeur) comme dépendance
-
Statut du fournisseur cloud / hébergement
Ajoute AWS, GCP, Azure, Vercel… comme dépendance
-
API tierces critiques
Ajoute OpenAI, Twilio, SendGrid… tout ce dont tes flux essentiels ont besoin
Commence par un check.
Gratuit pour 5 monitors, sans carte. Coche le reste de la liste au fur et à mesure.
Commencer gratuitement