Être prévenu quand un service tombe, ralentit ou répond autrement.

Granit Golem teste vos sites, API et bases de données, et compare chaque check aux 24 heures précédentes.

Six vérifications, sans créer de compte.

1,68
million de mesures du 4 septembre au 4 octobre 2026
15
types de checks
9
signaux comparés aux 24 heures précédentes
0
agent à installer

Un service en ligne n'est pas forcément un service qui marche.

Disponibilité 100 % Temps de réponse
Dérive détectée Il ralentit La disponibilité reste à 100 % pendant que le temps de réponse double.
GET /health 200 OK "status": "ok", "db": "up", "database": { "state": "up" }, "version": "2.4.1"
Structure modifiée Il répond autrement Le code reste 200, mais un champ a changé de nom dans la réponse.
Disponibilité Échecs consécutifs 123 = seuil atteint
Alerte envoyée Il tombe Après le nombre d'échecs consécutifs que vous fixez, l'alerte part.

Ce que vous voyez dans l'app.

  1. Disponibilité

    Chaque check vérifie que le service répond.

    Une alerte part après le nombre d'échecs consécutifs que vous fixez. Un certificat SSL est signalé avant son expiration.

    /projects/:id/dashboard
    Tableau de bord d'un projet : cinq checks opérationnels et la santé de chacun sur 24 heures
  2. Dérive

    Chaque check est comparé aux 24 heures précédentes.

    Toutes les 6 heures, Granit Golem compare 9 signaux : latence p50, p95 et p99, disponibilité, taux d'erreur, taux de succès, structure de la réponse, code HTTP et en-têtes.

    /projects/:id/checks/:checkId
    Page d'analyse de dérive, période de 7 jours choisie : la latence p95 passe de 138 à 192 ms par rapport à la semaine précédente
  3. Alertes et page de statut

    Votre équipe reçoit les alertes, vos utilisateurs voient la page de statut.

    Les alertes partent par e-mail, Slack, Discord, PagerDuty ou webhook. Une page de statut publique affiche l'état de chaque service.

    /status/granit-labs
    Page de statut publique : disponibilité de chaque service sur 15 jours
  4. Vue d'ensemble

    La carte des services montre ce qui dépend de quoi.

    Vous reliez vos composants et vous fixez des SLO : l'app suit le budget d'erreur restant et le rythme auquel il s'épuise.

    /projects/:id/service-map
    Carte des services : le CDN mène à la boutique, qui dépend de l'API de paiement et de la recherche
    /projects/:id/slos
    Liste des SLO : trois objectifs de disponibilité et leur budget d'erreur restant
Créer un compte gratuit

Captures de l'app, données de démonstration.

Deux dérives qui échappent à un simple test de disponibilité.

Performance, cas réel

Le 24 septembre 2026, le p95 d'un de mes services a doublé.

Du 4 au 23 septembre, il restait entre 63 et 86 ms, à part un pic à 111 ms le 19. Du 24 septembre au 3 octobre, il est resté entre 139 et 153 ms.

Le service n'a jamais cessé de répondre. L'écart ne se voyait qu'en comparant chaque journée aux précédentes.

60 100 140 avant le 24 sept. : 63–86 ms alerte le 25 sept. à 3 h 31 4 sept.24 sept.3 oct. 60 100 140 avant le 24 sept. : 63–86 ms alerte le 25 sept. à 3 h 31 4 sept.24 sept.3 oct.
p95 quotidien (jours UTC, 1 440 mesures par jour). Mesures réelles, adresse du service masquée.
Dérive 64 → 140ms p95 des 24 heures avant l'alerte, comparé aux 24 heures d'avant
Stable 99,79% disponibilité minimale pendant la dérive
Alerte 1 le 25 septembre à 3 h 31, heure de Paris
Durée 10jours p95 quotidien de 139 ms ou plus

Contenu, données de démonstration

Le code HTTP reste 200 alors que la réponse a changé.

Un champ renommé casse une application cliente sans faire tomber l'API. Granit Golem compare la structure des réponses et les en-têtes. Avec l'option de dérive bloquante, le check échoue dès que la structure change.

GET https://pay.example.com/health Code HTTP 200 → 200 Structure du body, changement significatif "status": string- "db": string- "queue": { "lag_ms": integer }+ "database": { "state": string } "version": string En-têtes, changement significatif cache-control content-type- x-ratelimit-limit- x-ratelimit-remaining

Dans quels cas l'utiliser.

  • Après une mise en production

    Une version peut ralentir une page ou modifier une réponse d'API sans rien casser en apparence.

  • Pour une API dont d'autres dépendent

    La structure des réponses et les en-têtes sont comparés d'une journée à l'autre.

  • Pour plusieurs sites ou clients

    Un projet par client, avec ses environnements et sa page de statut publique.

Le film, en une minute et demie.

Valeurs reconstituées, données de démonstration.

Ce que chaque type d'outil détecte.

PanneRalentissementRéponse modifiéeRien à installer
Outil d'uptime oui en partie, selon un seuil ou un mot-clé à régler en partie, selon un seuil ou un mot-clé à régler oui
Observabilité (Datadog, Grafana…) oui oui en partie, selon un seuil ou un mot-clé à régler non
Granit Golem oui oui oui oui

oui en partie, selon un seuil ou un mot-clé à régler non

Granit Golem ne fait pas d'APM et ne collecte ni traces ni logs.

Quinze types de checks.

Web et API 3
  • HTTP
  • certificat SSL
  • parcours en plusieurs étapes
Réseau 4
  • TCP
  • DNS
  • ping
  • SMTP
Bases et stockage 6
  • PostgreSQL
  • MySQL
  • MongoDB
  • Redis
  • Elasticsearch
  • S3
Pile ELK 2
  • Logstash
  • Kibana

Aussi dans l'app.

  • Heartbeats pour les tâches planifiées
  • Fenêtres de maintenance qui suspendent les checks
  • Checks rangés par environnement
  • Export CSV des exécutions
  • Rapport hebdomadaire par e-mail
  • Équipes et invitations
  • API documentée, clés d'API, webhooks sortants
  • Interface en français et en anglais

Fait à Nantes.

Portrait de Cédric Chariere Fiedler

Cédric Chariere Fiedler

Architecte web et API, Nantes

J'utilise Granit Golem sur mes propres services.

  • Chaque organisation est isolée en base, et les secrets de vos canaux sont chiffrés.
  • Limite connue : une dégradation très lente, de quelques pour cent par jour, peut passer inaperçue.

Questions fréquentes.

Quelle différence avec un outil d'uptime classique ?

Un outil d'uptime signale une panne, et une lenteur au-delà d'un seuil que vous fixez. Granit Golem compare en plus chaque check à son propre historique récent.

Faut-il installer quelque chose ?

Non. Les checks partent des serveurs de Granit Golem, donc une base de données doit être joignable depuis ces serveurs.

Combien d'alertes vais-je recevoir ?

Une par dérive significative, pas une par mesure. Le cas du 24 septembre n'en a déclenché qu'une.

Trois étapes pour démarrer.

  1. Ajoutez un check

    Une URL, un port ou une base de données, à la fréquence que vous choisissez.

  2. Choisissez vos canaux

    E-mail, Slack, Discord, PagerDuty ou webhook.

  3. Laissez tourner 48 heures

    La détection de dérive démarre dès que deux journées de mesures sont enregistrées.

Créer un compte gratuit

Gratuit pendant l'accès anticipé.

5
checks inclus

Inclus

  • Alertes
  • Pages de statut
  • SLO
  • Carte des services

Sans carte bancaire. Les tarifs ne sont pas encore fixés.

Plus de 5 checks, ou plusieurs clients ? Écrivez-moi.