Pour les équipes DevOps

Une surveillance depuis l'extérieur pilotable depuis votre pipeline

AlertSleep vérifie vos endpoints publics, vos ports, vos certificats et vos tâches planifiées depuis l'extérieur de votre réseau, confirme chaque échec avant d'alerter qui que ce soit, et reçoit ses instructions de votre CI via une simple API REST. Rien à installer sur vos serveurs.

  • Vérification toutes les 60 secondes
  • Fenêtres de maintenance depuis la CI
  • SMS et appels téléphoniques inclus
Couper les alertes pendant un déploiement, dans toute CI qui exécute curl
# .github/workflows/deploy.yml
- name: Mute AlertSleep during the deploy
  env:
    ALERTSLEEP_TOKEN: ${{ secrets.ALERTSLEEP_TOKEN }}
    MONITOR_ID: ${{ vars.ALERTSLEEP_MONITOR_ID }}
  run: |
    curl -fsS -X POST https://api.alertsleep.com/public/v1/maintenance-windows \
      -H "AuthToken: $ALERTSLEEP_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{\"title\":\"Deploy ${GITHUB_SHA::7}\",
           \"starts_at\":\"$(date -u +%FT%TZ)\",
           \"ends_at\":\"$(date -u -d '+20 min' +%FT%TZ)\",
           \"monitor_ids\":[\"$MONITOR_ID\"]}"

Pilotez-le depuis le pipeline

Aucun plugin à installer ni à maintenir à jour : chaque étape est une requête HTTP.

Surveiller un nouveau service

Après le premier déploiement d'un service, créez son moniteur dans la même tâche et conservez l'identifiant renvoyé pour les étapes suivantes.

# after a new service is deployed: watch its health endpoint
curl -fsS -X POST https://api.alertsleep.com/public/v1/monitors \
  -H "AuthToken: $ALERTSLEEP_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"friendly_name\":\"$SERVICE (prod)\",
       \"url\":\"https://$SERVICE.example.com/healthz\",
       \"type\":\"http\",\"interval_seconds\":60}" \
  | jq -r .monitor.id

Retirer un serveur du service

Mettez ses moniteurs en pause pendant qu'il est vidé ou reconstruit, puis réactivez-les à son retour. Un moniteur en pause n'envoie aucune alerte.

# taking a server out of service: stop checking it
curl -fsS -X PUT https://api.alertsleep.com/public/v1/monitors/$MONITOR_ID \
  -H "AuthToken: $ALERTSLEEP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "paused"}'

# back in service
curl -fsS -X PUT https://api.alertsleep.com/public/v1/monitors/$MONITOR_ID \
  -H "AuthToken: $ALERTSLEEP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "up"}'

Prouver que la sauvegarde a tourné

Signalez le démarrage, le succès ou le code de sortie. Une exécution qui ne démarre jamais, ne se termine jamais ou échoue déclenche l'envoi d'un e-mail.

#!/usr/bin/env bash
# nightly backup: report the start, the success or the exit code
set -o pipefail
PING=https://api.alertsleep.com/v1/ping/YOUR-TOKEN
curl -fsS "$PING/start"
if pg_dump "$DATABASE_URL" | gzip > /backups/db.sql.gz; then
  curl -fsS "$PING"
else
  curl -fsS "$PING/fail" -d exit_code=$? -d message="pg_dump failed"
fi

API publique sur /public/v1, un jeton d'API dans l'en-tête AuthToken, jusqu'à 500 requêtes par minute et par jeton. Une fenêtre de maintenance dure au maximum 24 heures : un pipeline qui plante en cours de route ne peut donc pas rendre vos moniteurs muets pour de bon. Plus d'exemples pour les développeurs

Moins de fausses alertes à 3 h du matin

Une alerte qui se révèle sans objet apprend à chacun à ignorer la suivante.

Confirmation depuis un second emplacement

Lorsqu'une vérification HTTP ou de mot-clé échoue, la même requête est aussitôt répétée depuis un second emplacement indépendant. Si elle passe de là-bas, personne n'est alerté.

Échecs consécutifs

Choisissez combien de vérifications échouées d'affilée, de 1 à 10, ouvrent un incident lorsqu'aucun second avis n'est disponible, par exemple sur un moniteur de port.

Fenêtres de maintenance

Les travaux planifiés ne déclenchent aucune alerte et ne font pas baisser votre disponibilité. Ouvrez une fenêtre dans le tableau de bord ou depuis le pipeline, et fermez-la plus tôt une fois le travail terminé.

Votre propre délai d'attente

Entre 5 et 60 secondes par moniteur : un endpoint lent mais sain reste au vert, et un endpoint bloqué passe au rouge.

Des canaux par moniteur

La production peut vous appeler sur votre téléphone, tandis que la préproduction se contente de publier dans un canal de discussion.

Prévenu quand c'est terminé

Un avis de rétablissement dès la première vérification réussie, et l'incident avec sa cause dans l'historique.

Où partent les alertes

Tous les canaux activés sur un moniteur sont alertés au même moment.

E-mail SMS Appel téléphonique Slack Microsoft Teams Discord Telegram WhatsApp Webhook
Toutes les intégrations
  • L'alerte indique ce qui a échoué : le code de statut, le délai dépassé, l'erreur DNS, de connexion ou TLS, ou le mot-clé manquant.
  • Le webhook envoie du JSON lors des événements monitor.down, monitor.up et des événements de certificat, signé en HMAC-SHA256 lorsque vous définissez un secret.
  • Les SMS et les appels téléphoniques sont inclus dans le forfait, à partir de $59 par an, sous forme de quota mensuel, sans packs de crédits à acheter.
  • Les appels téléphoniques et les SMS peuvent être rédigés en anglais, allemand, français, espagnol, polonais ou tchèque.

Ce qu'AlertSleep n'est pas

Pour que vous le sachiez avant de vous inscrire.

  • Il vérifie depuis l'extérieur et n'atteint donc que des adresses publiques. Les services situés sur un réseau privé ou derrière un VPN ne peuvent pas être surveillés, et il n'y a aucun agent à installer.
  • Il enregistre la disponibilité et le temps de réponse, pas des métriques : ni CPU ni mémoire, ni performances des requêtes, pools de connexions ou retard de réplication, ni logs ni traces.
  • Il ne découvre rien automatiquement. Il n'y a pas d'intégration Kubernetes ; chaque endpoint ou port est un moniteur que vous créez, dans le tableau de bord ou via l'API.
  • Il n'y a ni plugins de CI, ni provider Terraform, ni configuration YAML. curl dans une étape de pipeline fait le même travail.
  • Il n'y a pas d'intégration PagerDuty ou Opsgenie, ni de rotation d'astreinte. Le webhook générique peut alimenter un outil qui accepte les webhooks entrants.
  • Une vérification de port se limite à une connexion TCP ; UDP n'est pas pris en charge.

Questions fréquemment posées

Comment AlertSleep s'intègre-t-il à un pipeline CI/CD ?

Via l'API REST, avec curl ou n'importe quel client HTTP dans une étape de pipeline. Ouvrez une fenêtre de maintenance avant un déploiement et fermez-la ensuite, créez un moniteur pour un nouveau service, ou mettez en pause les moniteurs d'un serveur que vous retirez du service. Aucun plugin à installer.

Comment éviter les alertes pendant un déploiement ?

Ouvrez une fenêtre de maintenance pour les moniteurs concernés, depuis le tableau de bord ou par un POST sur /public/v1/maintenance-windows, et fermez-la une fois le déploiement terminé. Les vérifications continuent, mais aucune alerte ne part et la fenêtre ne fait pas baisser votre disponibilité. Une fenêtre dure au maximum 24 heures.

AlertSleep peut-il surveiller Kubernetes ?

Il peut surveiller ce que Kubernetes expose publiquement : les hôtes d'ingress, les endpoints de santé et les ports TCP sur des répartiteurs de charge publics. Il ne communique pas avec le cluster, ne découvre pas les services et ne voit pas les pods : chaque endpoint est donc un moniteur que vous créez, à la main ou via l'API depuis votre tâche de déploiement.

Puis-je surveiller des bases de données et des services internes ?

Uniquement s'ils sont accessibles depuis Internet. Un moniteur de port ouvre une connexion TCP vers une adresse publique et indique si elle a été acceptée. Les adresses privées sont refusées, et ni les performances des requêtes ni le retard de réplication ne sont mesurés.

AlertSleep s'intègre-t-il à PagerDuty ou Opsgenie ?

Pas directement. Les alertes partent par e-mail, SMS, appel téléphonique, Slack, Microsoft Teams, Discord, Telegram, WhatsApp et un webhook générique signé. Pour utiliser un outil d'astreinte, dirigez le webhook vers une intégration de cet outil qui accepte les webhooks entrants.

En combien de temps serai-je informé d'une panne ?

Les vérifications ont lieu toutes les 60 secondes. Une vérification HTTP ou de mot-clé échouée est aussitôt répétée depuis un second emplacement, et lorsque les deux concordent, l'alerte part immédiatement. Les moniteurs de port attendent le nombre d'échecs consécutifs que vous avez défini.

Existe-t-il un provider Terraform ou une configuration YAML ?

Non. Les moniteurs se créent dans le tableau de bord ou via l'API REST, qu'un script ou une étape de pipeline peut appeler pour aligner vos moniteurs sur ce que vous déployez.

Puis-je l'essayer gratuitement ?

Oui. Les deux forfaits commencent par un essai de 14 jours avec l'API, les fenêtres de maintenance et les alertes SMS inclus, sans carte bancaire. Après l'essai, le prix démarre à $59 par an.

Placez votre premier endpoint sous surveillance

Ajoutez-le dans le tableau de bord ou en un seul appel d'API, puis coupez ses alertes depuis votre prochain déploiement. Essai gratuit de 14 jours, sans carte bancaire.