InfraNestInfraNest

Surveillance & statut

Sachez que votre site est en panne avant vos clients

Surveillez sites web, API, ports, certificats, DNS, tâches cron et vos propres serveurs — vérifiés depuis l’Europe, l’Amérique du Nord et l’Asie-Pacifique en même temps, pour voir la panne que subissent vos clients à Francfort même quand tout semble normal depuis Ashburn. Un statut ne change que lorsqu’assez de régions sont d’accord : c’est pour cela que vous avez de nos nouvelles quand quelque chose ne va vraiment pas.

Offre gratuite · Sans carte · Premier moniteur en ligne en moins d’une minute

  • Vérifié depuis trois continents
  • Un incident, pas dix alertes
  • Onze choses qu’il peut surveiller
  • Directement vers Slack, Jira ou PagerDuty
MoniteursSurveillez tout ce qui a une adresse, depuis n’importe où.+ Ajouter un moniteur
MoniteurDernières 24 heuresDisponibilité
API healthHTTPEn ligne · HTTP 200 — OK100.0%
App — northwind-app.devHTTPEn ligne · HTTP 200 — OK100.0%
Checkout flowHTTPHors ligne · HTTP 503 — Service Unavailable96.9%
DocsHTTPEn ligne · HTTP 200 — OK100.0%
Mail — SMTPPortEn ligne · Connected in 24 ms100.0%
Marketing siteHTTPEn ligne · HTTP 200 — OK100.0%
6 moniteurs sur 12 affichés
Search APIAPIDégradé · HTTP 200 — OK, but the response-time assertion failed (1,240 ms)100.0%
API healthHTTPEn ligne · HTTP 200 — OK100.0%
App — northwind-app.devHTTPEn ligne · HTTP 200 — OK100.0%
Checkout flowHTTPHors ligne · HTTP 503 — Service Unavailable96.9%
DocsHTTPEn ligne · HTTP 200 — OK100.0%
Marketing siteHTTPEn ligne · HTTP 200 — OK100.0%
Staging appHTTPInconnu ·
Signup page copyKeywordEn ligne · HTTP 200 — OK100.0%
Mail — SMTPPortEn ligne · Connected in 24 ms100.0%
Postgres — db-01PortEn ligne · Connected in 24 ms100.0%
www → apex redirectRedirectEn ligne · HTTP 200 — OK100.0%
northwind.com certificateSSLEn ligne · Valid — 74 days remaining100.0%

Vérifié de partout, confirmé avant qu’on vous réveille

Chaque contrôle tourne en même temps depuis des sondes en Europe, en Amérique du Nord et en Asie-Pacifique. Qu’une seule échoue n’est pas une panne — c’est une sonde qui a eu une mauvaise seconde, et un outil de surveillance qui vous appelle pour cela vous apprend à l’ignorer. Un statut ne bascule donc que lorsqu’assez de sondes, dans assez de régions différentes, sont d’accord. Vous récupérez la panne que vos clients subissent vraiment, et vous cessez de recevoir celles qu’ils n’ont jamais remarquées.

  • Des sondes en Europe, en Amérique du Nord et en Asie-Pacifique, sur chaque contrôle
  • Un statut ne change que lorsque votre seuil de sondes — et de régions — est atteint
  • Des temps de réponse par région, pour que « c’est lent en Asie » soit quelque chose de visible
  • Le battement est amorti : un service qui rebondit ne vous appelle pas douze fois
Search API

https://api.northwind.com/v1/search

Vérifié depuis 3 régions · 2 sondes doivent être d’accord · 2 régions sur 3 doivent être d’accord

Europeen désaccord
Amérique du NordHTTP 200 — OK, but the response-time assertion failed (1,240 ms)
Asie-PacifiqueHTTP 200 — OK, but the response-time assertion failed (1,240 ms)

Un statut ne change que lorsque les seuils ci-dessus sont atteints — c’est pourquoi une région ayant une mauvaise seconde ne vous parvient jamais.

Onze choses qu’il peut surveiller, pas seulement « le site répond-il »

Un site qui renvoie 200, c’est le cas facile. InfraNest surveille aussi ce qui casse en silence : une tâche cron qui ne se signale plus, une API qui renvoie le mauvais champ JSON, une redirection qui a perdu sa destination, un certificat à trois jours de l’expiration, un port qui s’est fermé, un enregistrement DNS qui ne résout plus — et les serveurs en dessous, avec CPU, mémoire, disque et services remontés par l’agent. Il surveille même les pages de statut des autres, pour que la panne d’un fournisseur dont vous dépendez vous parvienne sans que vous rafraîchissiez la sienne.

  • Les moniteurs heartbeat attrapent la tâche cron qui s’est arrêtée en silence
  • Les moniteurs d’API vérifient des champs JSON, pas seulement le code de statut
  • Les moniteurs de serveur remontent CPU, mémoire, disque, charge et services
  • Les moniteurs de statut de service interrogent pour vous les pages de statut de vos fournisseurs
Que voulez-vous surveiller ?11 types

Ensuite, il demande

Une URL, et le code de statut que vous attendez

Une URL, et le mot-clé à trouver dans la réponse

Une URL, et l’URL finale sur laquelle vous devez arriver

Un domaine ou une IP, et le port

Un domaine, et combien de jours à l’avance vous prévenir

Un domaine, le type d’enregistrement, et la valeur attendue

Un domaine ou une adresse IP

Une URL, plus des assertions sur le JSON renvoyé

Rien — il vous donne une URL que votre tâche doit appeler

Quel serveur, et quelle métrique franchit quel seuil

Quel fournisseur, et lesquels de ses composants vous utilisez

Une panne, un incident — pas dix alertes

Quand la base de données tombe, tout ce qui est devant tombe aussi. La plupart des outils vous appellent alors une fois par contrôle, et vous passez les dix premières minutes d’une panne à chercher quelle alerte compte. Dites à InfraNest quels moniteurs dépendent de quels autres et il le fait pour vous : le parent qui tombe met ses enfants en sourdine, vous obtenez donc un seul incident nommant ce qui a réellement cassé, avec une chronologie à laquelle vous ajoutez des mises à jour. Le travail planifié entre dans une fenêtre de maintenance et ne se lit jamais comme une panne.

  • Déclarez ce qui dépend de quoi — un parent qui tombe fait taire ses enfants
  • Un incident avec une chronologie : détecté, confirmé, mis à jour, résolu
  • Les fenêtres de maintenance suspendent les alertes et marquent le travail comme planifié
  • Acquittez ou résolvez depuis l’alerte elle-même, ou depuis une automatisation
Titre
Checkout flow est hors ligne
Voir le moniteurRédiger le post-mortem
DuréeEn cours
MoniteurCheckout flow
Cause racineHTTP 503 — Service Unavailable
NotifiésSlack, PagerDuty
Impact
Statut
Détecté14:02Identifié14:053Sous surveillancemaintenant4Résolu
Chronologie
Sous surveillanceJasparLe basculement vers le serveur de secours est terminé. Nous surveillons les taux d’erreur avant de clore.
IdentifiéJasparLa base de données principale n’accepte plus de connexions. Tout ce qui est en amont est touché.
InvestigationSystemHTTP 503 — Service Unavailable
2 moniteurs mis en sourdine par celui-ci
API healthregroupé, sans alerte séparée
Search APIregroupé, sans alerte séparée

Quels moniteurs dépendent de quels autres, vous le déclarez une seule fois, par moniteur.

Là où part l’alerte, c’est tout l’enjeu

Une alerte que personne ne voit n’est pas de la surveillance. Envoyez les avertissements dans un canal Slack et les pannes franches vers PagerDuty, avec e-mail, Teams, Discord ou Telegram à côté — et réglez une destination sur « critique seulement », pour que le téléphone de 3 h du matin reste silencieux sur ce qui peut attendre lundi. Au-delà des canaux, une automatisation peut agir sur l’alerte au lieu de la relayer : ouvrir le ticket Jira ou Linear, créer l’issue GitHub, publier sur votre page de statut, POSTer vers votre propre point de terminaison, ou redémarrer le serveur et clore l’incident s’il revient.

  • E-mail, Slack, Teams, Discord, Telegram et PagerDuty
  • Une gravité par destination, pour que les canaux « critique seulement » restent silencieux le reste du temps
  • Des avis de rétablissement, pour que « c’est revenu ? » soit répondu sans demander
  • Ou confiez-la à une automatisation : Jira, Linear, Notion, GitHub, un webhook, un redémarrage
Prévenir ces destinationsChacune entend ce que vous lui faites entendre.

Ou laissez une automatisation agir

Créer un ticket JiraOuvrir une issue LinearCréer une issue GitHubPublier une annonce sur la page de statutAppeler un webhookRedémarrer le serveur

Tout ce qu’il gère par ailleurs

Les parties qui ne deviennent intéressantes que le jour où vous en avez besoin.

Pages de statut

Transformez ce que vous surveillez déjà en une page publique à vos couleurs, sur votre propre domaine — avec les incidents et les fenêtres de maintenance repris automatiquement.

Vos propres sondes

Faites tourner une sonde sur l’un de vos serveurs pour surveiller quelque chose qui n’est joignable que depuis votre réseau, à côté des sondes publiques.

Historique des temps de réponse

Temps de réponse par région conservés dans la durée, pour que « c’est devenu plus lent mardi dernier » soit quelque chose à montrer plutôt qu’à se rappeler.

Alertes sur les métriques serveur

Alertez quand le CPU, le disque ou le réseau d’un serveur franchit un seuil — avant que cela devienne un contrôle qui échoue.

Fenêtres de maintenance

Planifiez le travail, et les alertes, la page de statut et le chiffre de disponibilité comprennent tous les trois qu’il était prévu.

Automatisations sur les moniteurs

Mettre un moniteur en pause, le rendre muet une heure, ouvrir une fenêtre ou redémarrer un serveur, déclenché par ce que vous voulez.

Premier moniteur en ligne en moins d’une minute

Collez une URL. Aucun agent à installer, rien à configurer, et l’offre gratuite en garde vingt.

Le faire soi-même vs InfraNest

La différence entre savoir que quelque chose est tombé et s’entendre dire ce qui compte.

À la main

  • Une tâche cron qui fait un curl sur une URL depuis une machine, dans un pays
  • Chaque service dépendant qui vous appelle séparément pour une seule panne
  • Des alertes dans une boîte mail que personne ne lit à 3 h du matin
  • Une tâche cron arrêtée en silence, remarquée une semaine plus tard
  • Du travail planifié impossible à distinguer d’une vraie panne

Avec InfraNest

  • Des sondes sur trois continents qui doivent s’accorder avant que vous n’entendiez parler de quoi que ce soit
  • Un seul incident qui nomme ce qui a réellement cassé
  • Les avertissements vers Slack, les pannes franches vers PagerDuty, « critique seulement » là où il faut
  • Un moniteur heartbeat qui remarque le silence en quelques minutes
  • Des fenêtres de maintenance qui gardent le chiffre de disponibilité honnête

Un identifiant, dix modules

Chaque module est dans chaque offre, Free compris — seules les limites changent.

Le coût si vous le faisiez séparément

Chaque brique dans un outil différent, et l’addition grimpe vite :

Domaine & DNS
~30 €
Monitoring
~29 €
Suivi SSL
~15 €
Page de statut
~29 €
Panel serveur
~15 €
Sur 4–5 outils distincts
100–150 €/mois
InfraNest Business – tout ça, un seul accès49 €/mois

Comparer toutes les fonctionnalités →

Questions fréquentes

D’où partent les contrôles ?

De sondes en Europe, en Amérique du Nord et en Asie-Pacifique. Chaque contrôle tourne depuis plusieurs d’entre elles à la fois, et un statut ne change que lorsqu’assez de sondes — réparties sur assez de régions — sont d’accord : c’est ce qui empêche un site instable de vous appeler. Vous pouvez aussi faire tourner une sonde sur votre propre serveur pour surveiller quelque chose qui n’est joignable que depuis votre réseau.

Que peut-il surveiller ?

Sites web et API en HTTP, contrôles de mot-clé et de redirection, ports TCP, ping, enregistrements DNS, certificats SSL, moniteurs heartbeat pour les tâches cron, moniteurs d’API avec assertions JSON, le CPU, la mémoire, le disque et les services de vos serveurs, ainsi que les pages de statut d’autres fournisseurs.

Comment éviter qu’une panne m’appelle dix fois ?

Dites à InfraNest quels moniteurs dépendent de quels autres. Quand un parent tombe, ses enfants sont mis en sourdine : vous obtenez un incident qui nomme la cause racine au lieu d’une alerte par contrôle touché. Le battement est amorti séparément, pour qu’un service qui monte et descend ne vous appelle pas à chaque fois.

Où peuvent aller les alertes ?

E-mail, Slack, Microsoft Teams, Discord, Telegram et PagerDuty, et chaque destination peut être réglée sur une gravité — un canal « critique seulement » reste donc silencieux pour les avertissements. Une automatisation peut aller plus loin et ouvrir un ticket Jira, Linear, Notion ou GitHub, publier sur votre page de statut, appeler votre propre webhook, ou agir directement sur le serveur.

Surveiller une tâche cron demande-t-il un agent ?

Non. Un moniteur heartbeat vous donne une URL que votre script ou votre cron appelle en terminant. Si l’appel n’arrive pas dans la fenêtre que vous avez définie, vous êtes alerté — ce qui attrape la tâche arrêtée en silence, la panne qu’un contrôle d’URL ne peut jamais voir.

Que se passe-t-il pendant une maintenance planifiée ?

Ouvrez une fenêtre de maintenance : les contrôles qu’elle couvre cessent d’alerter, la page de statut indique que le travail était prévu, et votre chiffre de disponibilité n’en est pas pénalisé.

Vingt moniteurs, sur le plan gratuit

Collez une URL et surveillez-la depuis trois continents.

Offre gratuite · Sans carte bancaire · Configuré en quelques minutes