Aller au contenu
Essai gratuit

Pour les développeurs

Surveillance HTTP externe des points de terminaison que vous livrez.

UptimeWire interroge vos points de terminaison publics depuis l’extérieur, enregistre le code d’état et le temps de réponse, confirme les échecs et envoie les événements de panne et de rétablissement à vos outils.

Commencer la surveillance gratuitementAucune carte bancaire requise
Comment fonctionne une vérification
api.example/health Données de démonstration

Dernière vérification

Requête
GET
Redirections suivies
1
Statut final
200
Temps de réponse
184 ms
Résultat
En ligne

Ce que fait une vérification

Une simple requête GET, jugée sur son statut final.

Savoir exactement ce qu’est une vérification permet de mieux se fier à ses résultats.

Choisissez des points de terminaison qui répondent sans identifiants

Un 401 ou un 403 compte comme un échec : une route protégée paraîtra donc en panne. Surveillez une route de santé publique. La production et la préproduction sont des adresses distinctes, et chacune compte pour un site web.

Regardez un peu dans la réponse

Un échec peut aussi être déclenché quand le corps ne contient pas un texte, ou en contient un. La correspondance est exacte et lit le premier mégaoctet. Ce n’est pas une assertion JSON.

Une vérification en échec est répétée environ 20 secondes plus tard, et peut l’être depuis un second emplacement lorsqu’il est configuré, avant qu’un incident ne s’ouvre. La confirmation réduit les fausses alertes. Elle ne les supprime pas.

Événements sortants

Recevez les événements de panne et de rétablissement là où votre code peut les exploiter.

À partir de Starter, un webhook envoie un message JSON signé à l’ouverture d’un incident et à sa clôture. La signature est une HMAC-SHA256 calculée avec un secret que seuls vous et UptimeWire connaissez.

  • Une adresse de webhook par compte, partagée par tous vos sites web
  • Un message peut arriver en double ou dans le désordre : appuyez-vous sur l’identifiant et l’heure de début qu’il contient
  • Les webhooks ne transportent que les pannes et les rétablissements. Les avertissements de certificat, de domaine et de DNS vont par e-mail et Telegram

Comment fonctionnent les webhooks, avec les en-têtes et les règles de nouvelle tentative

Autres destinations

  • E-mail et Telegram avec toutes les offres
  • Discord à partir de Starter
  • Slack et Microsoft Teams à partir de Business

Remarque

Les webhooks sont développés et testés avec un récepteur de test. L’envoi vers une adresse publique réelle n’a pas encore été vérifié de façon indépendante. Envoyez le message de test vers votre propre point de terminaison avant de vous y fier.

API en lecture seule et serveur MCP

Récupérez vos données de surveillance dans vos propres outils.

À partir de Business, une clé d’API donne un accès en lecture à vos sites, incidents et à la disponibilité. Un serveur MCP permet aussi à un assistant IA de lire vos données de surveillance.

Ce que vous pouvez lire

Vos sites web
GET /api/v1/sites
Un site web
GET /api/v1/sites/{id}
Ses incidents
GET /api/v1/sites/{id}/incidents
Sa disponibilité
GET /api/v1/sites/{id}/uptime

Comment ça marche

  • Envoyez votre clé dans un en-tête Authorization, comme jeton Bearer
  • L’API ne fait que lire. Elle ne peut ni ajouter, ni modifier, ni supprimer de sites web
  • Le serveur MCP pour les assistants IA ne fait lui aussi que lire, et il a ses propres clés
  • Il n’existe pas de SDK officiels

Sa place

Un signal de plus, venu de l’extérieur.

UptimeWire répond bien à une seule question : l’adresse publique répond-elle ? Vos propres outils répondent au reste.

Ce qu’il vous apporte

  • Une vision indépendante de la disponibilité, depuis l’extérieur de votre réseau
  • L’historique des codes d’état et des temps de réponse de chaque point de terminaison
  • Des incidents avec un début, une cause et une durée
  • Des vérifications du certificat, du domaine et du DNS pour chaque adresse

Ce qu’il ne fait pas

  • Des tests dans un navigateur, des parcours scénarisés ou des requêtes personnalisées
  • Des journaux, des traces, du suivi d’erreurs ou des métriques serveur
  • Une intégration CI/CD ou une remédiation automatique
  • Vérifier une charge JSON par rapport à un schéma

Choix de l’offre

Free pour essayer, Starter pour les événements, Business pour l’API.

Comparer les offres

Questions fréquentes

Avant de commencer.

Puis-je envoyer des en-têtes personnalisés, un corps, ou utiliser POST ?

Non. Chaque vérification est une simple requête GET. Les requêtes ne sont pas personnalisables.

Puis-je surveiller un point de terminaison qui demande une authentification ?

Pas directement. La requête ne contient aucun identifiant : une route protégée répond donc 401 ou 403, ce qui compte comme un échec. Surveillez plutôt une route de santé publique.

Remplace-t-il l’APM, les journaux ou le traçage ?

Non. Il n’a ni journaux, ni traces, ni suivi d’erreurs, ni métriques serveur. Il ajoute une vue extérieure qui dit si vos adresses répondent.

Existe-t-il un SDK ou une intégration CI ?

Non. Il n’y a ni SDK ni intégration CI/CD. Vous pouvez utiliser les webhooks signés et, à partir de Business, l’API en lecture seule et un serveur MCP pour les assistants IA.

Les webhooks ont-ils été testés avec un service réel ?

Ils sont développés et testés avec un récepteur de test. L’envoi vers une adresse publique réelle n’a pas encore été vérifié de façon indépendante, et les pages d’intégrations le précisent.

Ajoutez une vérification extérieure à votre stack.

Surveillez gratuitement votre premier point de terminaison. Les quatre vérifications sont incluses.

Commencer la surveillance gratuitementAucune carte bancaire requise
Lire la page sur les webhooks

Intégrations

Guides

Glossaire

Plus