Surveillance de la disponibilité pour SaaS — vous le savez avant le premier ticket.
Uptimia attribue à votre API publique, à votre parcours de connexion et à la tâche de facturation de la nuit dernière une vérification qui leur est propre, plutôt que de deviner à partir d’une page d’accueil qui continue de charger. Une panne est confirmée depuis plusieurs régions avant d’alerter la personne d’astreinte — dans Slack, PagerDuty ou partout où votre équipe regarde.
Step breakdown
All 2 steps passedFailed at step 2244 ms · 02:13236 ms · 02:147-day averagesLast runAssertions — step 2
3 of 3 passing0 of 3 passedResponse — step 2
200 · 96 ms502 · 84 msRecent Runs
every minute · rotating locations
New York✗ Failed at step 20.24 s
Frankfurt✗ Failed at step 20.24 s
London✓ All 2 steps passed0.25 s
Sydney✓ All 2 steps passed0.26 s
Amsterdam✓ All 2 steps passed0.23 sNew York✓ All 2 steps passed0.24 s
Tokyo✓ All 2 steps passed0.25 sQuatre convictions qui font perdre des clients SaaS
Chacune paraît raisonnable — et chacune laisse une panne se poursuivre jusqu’à ce qu’un client la découvre.
« Si quelque chose se cassait, les clients nous le diraient. »
Ceux qui vous préviennent sont les clients fidèles. Un prospect qui tombe sur une inscription cassée ferme l’onglet et ne devient jamais client — personne ne se plaint, et rien n’atterrit dans votre boîte de réception.
« Nous sommes chez AWS — la disponibilité, c’est leur travail. »
Leur SLA couvre leur infrastructure, pas votre produit. Un déploiement raté, un certificat expiré, un worker de file bloqué — tout cela vous appartient, et la page de statut du fournisseur reste verte à chaque fois.
« L’application charge, donc tout fonctionne. »
Un SaaS est un ensemble de fonctionnalités, pas une seule page. Le tableau de bord peut charger pendant que l’API publique cesse de répondre, que la connexion échoue ou que la tâche de facturation saute une nuit en silence — chacune tombe en panne indépendamment, et « ça fonctionne » masque tout cela.
« Reconnaître publiquement les incidents nous donne une mauvaise image. »
Le silence donne une image pire encore. Un client qui trouve un message sur la page de statut n’ouvre aucun ticket — et se souvient que vous l’avez prévenu avant même qu’il ne demande. Un client qui ne trouve rien suppose que vous ne le savez pas non plus.
« Trois neuf, c’est quasiment parfait » est la plus répandue. 99,9 % de disponibilité autorisent 43 minutes de panne par mois. Sur un site vitrine, c’est une erreur d’arrondi — mais les clients travaillent à l’intérieur d’un SaaS. Multipliez 43 minutes par 500 clients : 21 500 client-minutes, soit 358 heures par mois où quelqu’un tombe sur votre produit en panne.
Les renouvellements ne se décident pas sur votre pourcentage de disponibilité. Ils se décident sur qui l’a découvert en premier, et à quelle vitesse c’est réparé.
Voici à quoi ressemble cette panne lorsqu’une chaîne surveille le point de terminaison.↓ minute par minute
Une panne d’API, du début à la fin
Le point de terminaison « compte » a cessé de fonctionner. Le tableau de bord chargeait toujours, le ping de la page d’accueil restait vert, et chaque intégration appelant ce point de terminaison échouait déjà.
Voilà pour l’API. Mais un SaaS tombe en panne sur quatre couches — app, API, parcours, tâches — et chacune échoue indépendamment des autres.↓ chaque couche
Chaque couche de votre produit, sous surveillance
Des vérifications sollicitent votre API et vos pages, un navigateur réel rejoue la connexion et l’inscription, vos tâches envoient un ping, et un script rapporte ce qu’ont vécu vos utilisateurs réels — le tout dans un seul tableau de bord, avec une seule liste de contacts.
Conçu pour la façon dont un SaaS tombe en panne
L’API que vos clients appellent
Une page d’accueil qui charge ne dit rien du point de terminaison que leurs intégrations sollicitent — c’est donc un client qui vous l’apprend aujourd’hui. Uptimia exécute à la place une véritable chaîne de requêtes contre votre API publique, jusqu’à chaque minute : se connecter, récupérer le jeton, appeler le point de terminaison protégé, lire la réponse.
- Des chaînes de jusqu’à 15 étapes — chaque étape vérifie la réponse reçue et transmet ce qu’il faut à la suivante
- Se connecte d’abord — elle s’authentifie, puis appelle les points de terminaison accessibles uniquement à un client connecté
- Confirmé, pas aléatoire — une étape en échec est vérifiée depuis jusqu’à trois emplacements avant l’ouverture d’un incident
Connexion et inscription, testées avant vos clients
Après un déploiement, la première tentative de connexion devrait venir d’un robot. Uptimia rejoue la connexion et l’inscription dans un navigateur réel depuis 13 emplacements, jusqu’à toutes les 10 minutes, et ouvre un incident dès qu’une étape échoue — avec une capture d’écran de la page au moment de la panne.
- Un navigateur réel — accède à la page, remplit les champs, clique, vérifie ce qui s’affiche
- Capture d’écran en cas d’échec — la cascade montre l’étape qui a échoué et l’apparence de la page
- Durées par étape — la durée de chaque étape, pour qu’un parcours qui ralentit se voie avant de tomber en panne
La tâche de facturation qui n’a jamais tourné
Un cron qui meurt ne le signale pas — rien ne paraît « en panne » de l’extérieur pendant que les factures ne partent pas, en silence. Les signaux de présence renversent la logique : votre tâche envoie un ping à Uptimia quand elle se termine, et un ping manquant est l’incident.
- Une seule URL de ping — une ligne à la fin d’un cron, d’un worker ou d’un script de sauvegarde
- Vous définissez l’échéance — une planification et un délai de tolérance ; un ping qui n’arrive jamais ouvre l’incident
- Aussi des signaux de démarrage & d’échec — détecte une tâche qui a démarré sans jamais se terminer, ou qui signale elle-même son échec
Une page de statut sur votre domaine
Avant d’ouvrir un ticket, un client cherche une page qui dit que vous êtes déjà au courant. Installez-en une sur votre propre domaine — votre logo, le badge Uptimia désactivé — montrant l’état en direct, 90 jours d’historique et chaque note d’incident, avec un e-mail envoyé aux abonnés à chaque mise à jour.
- Votre domaine, SSL automatique —
status.yourapp.comen HTTPS, le badge « Powered by Uptimia » amovible - Sections & abonnés — regroupez les sondes par domaine, publiez des mises à jour d’incident et de maintenance, prévenez les abonnés
- Publique ou privée — ouverte à vos clients, ou protégée par mot de passe
Un incident, votre équipe et votre page de statut
Le même incident confirmé alerte la personne d’astreinte et met à jour la page que vos clients sont déjà en train d’actualiser.
Microsoft Teams12 canaux d’alerte, une seule liste de contacts — et la page de statut que vos clients surveillent, mise à jour à partir du même incident.
Parcourir l’annuaire complet des intégrations →Une panne devrait vous alerter.Pas vos clients.
L’essai de 30 jours débloque tous les types de sondes — chaînes API, parcours de connexion, signaux de présence et vérifications de disponibilité.
Configurez la surveillance de votre SaaS en trois étapes
Les parcours critiques de votre produit peuvent être sous surveillance dès cet après-midi.
Pointez des vérifications vers votre produit
Ajoutez une vérification de disponibilité sur l’application, une chaîne de requêtes contre votre API publique, et une reprise de la connexion dans un navigateur réel.
Intégrez des signaux de présence à vos tâches
Ajoutez l’URL de ping à la fin de chaque cron, worker ou sauvegarde — un ping manqué devient un incident.
curl -fsS uptimia.com/p/hb_9f3c…
Routez les alertes & publiez le statut
Envoyez les alertes vers Slack et PagerDuty, choisissez qui est alerté ensuite si personne n’acquitte, et placez la disponibilité et les parcours sur une page de statut.
Également inclus
Observez le ressenti de vos utilisateurs réels
Un script JavaScript passif rapporte les temps de chargement de vos visiteurs réels, par appareil, navigateur et localisation.
Automatisez depuis l’API
Créez des sondes et des pages de statut depuis vos propres outils — lancez des vérifications dans un script de déploiement.
Fenêtres de maintenance
Vous livrez une release ? Planifiez la fenêtre — les vérifications se mettent en pause, les alertes restent silencieuses, la page de statut affiche les travaux prévus.
Un incident, une alerte
Une tempête d’alertes devient un seul résumé, pas cent notifications — avec un lien signé pour acquitter et un MTTA suivi.
Avis de rétablissement
Quand l’API revient, les ingénieurs qui ont été alertés reçoivent aussi le tout-va-bien.
Des outils gratuits pour déboguer ensuite
Tracez une redirection en-tête par en-tête avec le HTTP Status Checker, ou découvrez ce que permet chaque « neuf » avec le Uptime Calculator.
Qu’est-ce que la surveillance de la disponibilité pour SaaS ?
La surveillance de la disponibilité pour SaaS consiste à observer les parties d’un produit dont dépendent vos clients — l’API publique, les parcours de connexion et d’inscription, et les tâches en arrière-plan qui les sous-tendent — pour que votre équipe soit alertée dès que l’une d’elles tombe en panne. Le ping de la page d’accueil reste vert pendant que votre API cesse de répondre, que la connexion échoue, ou qu’une tâche nocturne s’arrête.
Vert pendant que les clients sont bloqués
Votre vérification réussit pendant que ce pour quoi les clients paient est en panne — vous l’apprenez par un ticket.
Vous surveillez chaque couche
Les vérifications API, parcours et tâches alimentent un seul pipeline — la panne atteint un ingénieur, pas un client.
Combien de temps d’arrêt permet chaque « neuf »
« 99,9 % de disponibilité » paraît imparable jusqu’à ce qu’on le convertisse en minutes — voici ce que permet chaque niveau.
Ouvrir le calculateur de disponibilité →| Disponibilité | Temps d’arrêt / mois | Temps d’arrêt / an |
|---|---|---|
| 99% | 7h 18m | 3d 15h |
| 99.9% | 43m 49s | 8h 46m |
| 99.95% | 21m 54s | 4h 23m |
| 99.99% | 4m 23s | 52m 35s |
| 99.999% | 26s | 5m 15s |
FAQ sur la surveillance SaaS
01Qu’est-ce que la surveillance de la disponibilité pour SaaS ?+
02En quoi est-ce différent d’un simple ping de ma page d’accueil ?+
03Puis-je surveiller mon API publique ?+
{{variable}} entre les étapes. Elle s’exécute jusqu’à chaque minute sur tous les forfaits, et une étape en échec est réexécutée depuis jusqu’à trois emplacements avant l’ouverture d’un incident. Une chaîne est la vérification la plus coûteuse à exécuter, c’est pourquoi les sondes API disposent de leur propre quota par forfait — les tarifs indiquent les chiffres.04Peut-elle détecter une connexion ou une inscription cassée ?+
05Puis-je être alerté quand une tâche en arrière-plan s’arrête ?+
06À quelle fréquence peut-elle vérifier ?+
07Puis-je offrir une page de statut à mes clients ?+
08Puis-je restreindre un coéquipier à certaines sondes seulement ?+
09Prenez-vous en charge le SSO, et puis-je obtenir des rapports SLA ?+
10Quels canaux d’alerte mon équipe peut-elle utiliser ?+
11Dois-je installer quoi que ce soit dans mon application ?+
curl vers l’URL de ping) ; la surveillance des utilisateurs réels est un petit script JavaScript. Aucun agent n’est nécessaire, sauf si vous voulez aussi des métriques serveur.Votre API, vos parcours et vos tâches, sous surveillance
Mettez votre API, votre parcours de connexion et vos tâches en arrière-plan sous surveillance dès cet après-midi — et cessez d’apprendre les pannes par vos clients.