Surveillance de site web pour développeurs, intégrée à votre stack.
Uptimia exécute vos véritables appels API — se connecter, récupérer le jeton, passer la commande, la relire — et vérifie chaque réponse. Donnez à chaque tâche cron une URL de signal de présence, créez des sondes depuis votre script de déploiement, et soyez alerté dans Slack, Discord ou PagerDuty.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sQuatre pannes qui ne lèvent jamais d’exception
Les quatre sont vraies le jour du déploiement. Aucune ne le reste d’elle-même — et quand l’une cesse de l’être, rien ne lève d’exception.
« Si quelque chose cassait, on verrait une exception. »
Les outils de suivi d’erreurs ne voient que le code qui s’exécute. Une entrée cron qui ne démarre jamais, un worker coincé en plein job, un certificat qui expire silencieusement — aucun d’eux ne lève d’exception. Les pires pannes ne sont pas des stack traces ; ce sont des silences.
« Le pipeline est vert, donc la prod va bien. »
L’intégration continue prouve que le code était bon au moment du déploiement. Jetons expirés, disques pleins, quotas épuisés et configuration qui dérive : tout cela se produit entre deux déploiements — dans le système en production, que votre suite de tests ne revoit plus jamais.
« On le saurait vite — on est en ligne toute la journée. »
Vous êtes devant un clavier 40 des 168 heures de la semaine — personne ne surveille les 128 autres. Et les utilisateurs signalent rarement un checkout cassé ; ils réessaient une fois et repartent.
« Ça marchait en staging, donc ça marche. »
L’environnement de staging n’a jamais le trafic, le volume de données, les quotas tiers ni le DNS de la production. Les modes de défaillance qui vous alertent à 3 h du matin sont précisément ceux que le staging ne peut pas reproduire.
« On a un endpoint /health — on est couverts » est la plus grande de toutes. Une vérification de santé chaque minute vous dit 1 440 fois par jour qu’un processus répond (24 × 60). Le nombre de ces vérifications qui prouvent que le checkout va jusqu’au bout, que la sauvegarde nocturne s’est bien déroulée ou que la file d’attente se vide : zéro.
« Un processus répond » et « le système fonctionne » sont deux affirmations différentes — et une seule d’entre elles compte pour vos utilisateurs.
Voici à quoi ressemble une tâche cron morte en silence quand un signal de présence est à l’écoute.↓ minute par minute
Ce qui se passe quand une tâche cron s’arrête en silence
Un déploiement a réécrit la crontab et fait sauter une ligne. Cette nuit-là, le worker de facturation n’a pas démarré, n’a rien signalé, et tous les tableaux de bord sont restés au vert — la file d’attente n’a jamais bougé.
Voilà pour le job qui est mort. Mais cron n’est qu’une des surfaces qui tombent en panne sans un bruit — chaque conviction ci-dessus a la sienne.↓ une sonde pour chacune
Chaînes, pings et agents
Des chaînes API pour les services, des pings entrants pour les jobs, des parcours en navigateur réel pour les checkouts, un agent en une ligne pour la machine. Des surfaces différentes, un seul flux d’incidents, une seule API.
Chaînes, signaux de présence et escalades
Appels enchaînés, vérifiés à chaque étape
Un endpoint /health prouve qu’un processus répond. Il ne prouve rien sur le parcours qui se cache derrière. La chaîne exécute les véritables appels dans l’ordre et vérifie chaque réponse — le code de statut, le temps qu’elle a mis, une valeur dans le JSON — jusqu’à une fois par minute sur chaque forfait payant, depuis tous les emplacements ou seulement ceux que vous choisissez.
- Jusqu’à 15 étapes — GET, POST, PUT, PATCH, DELETE ou HEAD, exécutées dans l’ordre
- Extraire et réutiliser — récupérez une valeur dans une réponse et injectez-la dans la suivante avec
{{token}} - Vérifiez ce qui compte — code de statut, temps de réponse, une valeur JSONPath, un en-tête ou du texte dans le corps, à chaque étape
/health répond sans problème pendant tout ce temps — et ne prouve aucun de ces quatre appels.
0 sur 4 prouvés
Le job qui n’a jamais démarré
Un job qui s’arrête devient silencieux, pas rouge — rien ne lève d’exception, donc rien n’alerte. Donnez-lui une URL de signal de présence à pinguer à chaque exécution, et le ping manquant devient l’alarme : dépassez la fenêtre au-delà du délai de grâce, et Uptimia ouvre un incident. Signalez aussi le début et la fin, et vous détectez également les jobs qui restent bloqués au lieu de s’arrêter.
- Intervalle ou planification cron — un simple intervalle ou une expression cron à 5 champs dans le fuseau horaire de votre compte
- Une ligne à brancher — extraits prêts à copier-coller pour Crontab, Bash, PowerShell, GitHub Actions et PHP
- Détecte les blocages, pas seulement les absences — envoyez un ping de départ, et une limite de durée d’exécution signale un job qui ne se termine jamais
Des sondes créées depuis votre étape de déploiement
Personne ne clique sur rien — le script qui a déployé le service a créé sa propre sonde. Créez et gérez vos sondes via l’API REST depuis une étape d’intégration continue, et quand un incident s’ouvre, un webhook personnalisé l’envoie en POST vers ce que vous utilisez déjà : un tableau de statut, un bot, un flux ChatOps.
- Une API REST — créez, lisez, modifiez et supprimez des sondes sur chaque forfait (les sondes API et signaux de présence se trouvent sur la v2), avec des clés API de compte gérées dans les paramètres
- Webhooks personnalisés — envoyez en POST un corps JSON fixe avec vos propres en-têtes vers n’importe quel endpoint lors d’un événement de sonde
- Sûr par défaut — la livraison des webhooks est vérifiée par TLS, épingle le DNS au moment de l’envoi et rejette les cibles situées sur des réseaux privés
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
D’abord Slack, puis PagerDuty si personne n’acquitte
Dans le canal que votre équipe surveille déjà, pas dans une boîte de réception que personne n’ouvre la nuit. L’escalade fait monter un ping Slack resté sans réponse jusqu’à une alerte PagerDuty selon votre calendrier, et une seule confirmation — donnée directement dans l’alerte, sans connexion — met en pause toutes les étapes en attente pour tout le monde.
- Des alertes là où vous travaillez — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, e-mail, SMS, webhooks et plus encore
- Politiques d’escalade — jusqu’à 10 étapes chronométrées par politique ; confirmez depuis l’alerte et l’escalade se met en pause
- D’abord confirmé — les pannes sont vérifiées depuis plusieurs régions — tout comme les jobs en retard au-delà de leur délai de grâce — avant que quiconque ne soit alerté
Alerté là où vous travaillez déjà, pas dans un tableau de bord supplémentaire
Un worker qui s’est arrêté, une chaîne qui a cassé, une machine à court d’espace disque — tout cela arrive dans les mêmes canaux, et tout cela est scriptable via l’API REST.
Microsoft TeamsUne seule liste de contacts — configurée une fois, depuis l’API ou l’interface.
Parcourir l’annuaire complet des intégrations →Un déploiement cassé devrait vous alerter.Pas vos utilisateurs.
L’essai de 30 jours débloque chaque type de sonde et chaque canal d’alerte.
Configurer votre première sonde en trois étapes
Pointez-la vers une surface, routez l’alerte, et laissez-la tourner.
Choisissez la surface
Une chaîne API, une URL de signal de présence, un parcours navigateur ou l’agent en une ligne — créez-le dans l’interface ou via l’API REST.
Routez l’alerte
Envoyez-la vers Slack, Discord ou PagerDuty, ajoutez un webhook, et décidez qui est alerté ensuite si personne n’acquitte.
Laissez-la tourner
Les vérifications s’exécutent depuis plus de 171 points de contrôle et confirment une panne avant de vous alerter — en nommant l’étape ou le job en cause.
Également inclus
Agent serveur en une ligne
CPU, mémoire, disque et charge depuis l’intérieur de la machine — une installation bash vérifiée par somme de contrôle, aucun collecteur à écrire. Linux, via un timer systemd ou cron.
Surveillance des transactions
Rejouez une connexion ou un checkout dans un navigateur réel — construit étape par étape dans l’éditeur, avec une capture d’écran de ce que chaque étape a vu.
Fenêtres de maintenance
Vous déployez ce soir ? Planifiez la fenêtre — les vérifications se mettent en pause, les alertes restent silencieuses, aucune fausse alerte pendant une mise en production planifiée.
Avis de rétablissement
Quand un service revient, les personnes qui ont été alertées en sont informées aussi — plus de « c’est encore en panne ? » qui traîne dans le canal.
Historique des incidents
Chaque incident est consigné avec ce qui s’est déclenché, quand, combien de temps a pris la reprise et — quand une escalade est en cours — qui l’a acquitté.
Une seule liste pour les chaînes et les jobs
Les chaînes API, les signaux de présence, les serveurs et les vérifications de disponibilité partagent un seul tableau de bord, une seule colonne vertébrale d’alerte et une seule API — pas quatre outils distincts.
Qu’est-ce que la surveillance de site web pour développeurs ?
La surveillance de site web pour développeurs consiste à surveiller les surfaces que vous mettez en production — API HTTP, jobs en arrière-plan, serveurs et parcours utilisateurs — et à vous alerter via les outils que vous utilisez déjà quand l’une d’elles casse. Vous intégrez la surveillance directement à votre stack : une vérification API multi-étapes depuis l’extérieur, un ping de signal de présence qu’une tâche cron envoie, un agent à l’intérieur de la machine, et une API REST avec des webhooks quand vous préférez tout scripter.
Elle répond, et c’est quand même cassé
Un ping superficiel reste au vert pendant que le parcours dont dépendent vos utilisateurs échoue.
La chaîne le détecte
L’assertion en échec nomme l’appel exact — vous commencez donc à déboguer, pas à deviner.
Quelle sonde surveille quoi
Chaque famille surveille une surface différente — toutes partagent un seul tableau de bord, une seule colonne vertébrale d’alerte et une seule API REST. Chacune est aussi comptée séparément, et une chaîne est la ligne la plus coûteuse à exécuter — la page tarifs indique les chiffres par forfait.
Voir tous les types de sondes →| Surface | Ce qui est détecté | Comment ça marche |
|---|---|---|
| Chaîne API | Parcours multi-étapes cassés | Jusqu’à 15 étapes ordonnées avec des assertions à chaque étape, vérifiées jusqu’à une fois par minute |
| Signal de présence | Tâches cron & workers qui s’arrêtent en silence | URL de ping entrant ; une fenêtre manquée au-delà du délai de grâce ouvre un incident |
| Disponibilité | Pannes, erreurs serveur | Vérifications depuis l’extérieur jusqu’à toutes les 30 s à partir du forfait Professional, confirmées depuis jusqu’à 3 régions |
| Agent serveur | Pression sur le CPU, la mémoire, le disque | Agent Linux en une ligne, qui remonte /proc + df toutes les 30 s |
| Transaction | Connexions & checkouts cassés | Parcours multi-étapes rejoués dans un navigateur réel |
FAQ sur la surveillance pour développeurs & DevOps
01Qu’est-ce que la surveillance de site web pour développeurs ?+
02Puis-je surveiller un parcours API multi-étapes, pas seulement un seul endpoint ?+
{{token}}, et vérifiez à chaque étape le code de statut, le temps de réponse, une valeur JSONPath, un en-tête ou du texte dans le corps. Si une étape échoue, l’alerte la nomme — vous savez exactement quel appel a cassé.03Comment surveiller une tâche cron ou un worker en arrière-plan ?+
curl pour qu’il pingue à chaque exécution. Définissez un intervalle ou une planification cron avec un délai de grâce, et si le ping n’arrive pas, un incident s’ouvre. Un ping de départ associé à une limite de durée d’exécution détecte aussi les jobs qui restent bloqués. Des extraits sont disponibles pour Crontab, Bash, PowerShell, GitHub Actions et PHP.04Existe-t-il une API de surveillance de la disponibilité pour créer et gérer des sondes ?+
curl prêt à copier. Il n’existe ni fournisseur Terraform ni application Zapier.05Puis-je attribuer une clé API distincte à chaque membre de l’équipe ?+
06Où vont les alertes, et puis-je les rediriger vers mes propres outils ?+
07Gérez-vous les rotations d’astreinte ?+
08L’agent serveur fonctionne-t-il sous Windows ?+
/proc et df pour le CPU, la mémoire, le disque et la charge. Un collecteur PowerShell pour Windows et un autre pour macOS sont fournis avec, et envoient le même payload — à l’exception des chiffres par cœur et d’attente E/S que seul Linux expose — mais ils ne vous sont pas remis sous forme de commande unique. Les hôtes Windows peuvent aussi être surveillés depuis l’extérieur avec des sondes de disponibilité, d’API ou de transaction.09Puis-je importer une commande cURL ou une spécification OpenAPI dans l’éditeur d’API ?+
10Combien de chaînes, de signaux de présence et d’agents un forfait inclut-il ?+
Déployez-le. Nous le surveillerons.
Intégrez une chaîne API, un signal de présence et un agent serveur à votre essai — les alertes vous parviennent là où vous êtes déjà.