Comparaison honnête

Sentinel vs Uptime Kuma

Uptime Kuma vérifie que la porte d'entrée répond. Sentinel regarde ce qui se passe dans les pièces derrière.

La version honnête

Uptime Kuma est gratuit, sous licence MIT, auto-hébergé et franchement bon dans son domaine. Si votre besoin, ce sont des checks HTTP, TCP, ping et DNS sur une poignée d'endpoints, il est très difficile à battre à zéro euro — et il embarque plus d'intégrations de notification que Sentinel n'en aura avant longtemps. Les deux ne sont pas vraiment concurrents : ils regardent depuis les deux côtés du même mur.

Côte à côte

Pas d'astérisque, et aucune ligne inventée pour avantager une colonne.

Point de vue
Uptime Kuma — De l'extérieur — HTTP, TCP, ping, DNS
Sentinel — De l'intérieur du cluster — état des réplicas, disponibilité des nœuds — plus tout signal que vous poussez
Ce qu'il peut voir
Uptime Kuma — Si l'endpoint répond
Sentinel — 2 réplicas prêts sur 3, un nœud passé NotReady, une pression mémoire — avant que l'endpoint cesse de répondre
Kubernetes
Uptime Kuma — Aucune intégration native — vous checkez l'URL de l'ingress
Sentinel — Un opérateur, avec découverte automatique par annotation
Ajouter un service
Uptime Kuma — Créer un monitor par endpoint, dans l'interface
Sentinel — Annoter le workload — le service se crée tout seul au premier signal
Canaux de notification
Uptime Kuma — Plus de 90 fournisseurs intégrés
Sentinel — Slack, Discord, e-mail et webhooks génériques — avec retries, cooldown et circuit breaker
Qui l'exploite
Uptime Kuma — Vous l'hébergez — et vous héritez du problème de surveiller la surveillance
Sentinel — Hébergé en Europe ; l'agent de collecte est open source
Coût
Uptime Kuma — Gratuit, plus une VM et votre temps
Sentinel — Offre gratuite, puis 9 € HT par mois

Alors, lequel choisir ?

Restez sur Uptime Kuma si

  • Vous surveillez surtout des endpoints publics et il vous dit déjà ce qu'il vous faut.
  • Vous ne voulez aucun prestataire dans la boucle, par principe ou par politique interne.
  • Vous dépendez d'un de ses fournisseurs de notification les plus exotiques.

Essayez Sentinel si

  • Vous faites tourner Kubernetes et voulez savoir qu'un workload est dégradé avant qu'il soit mort.
  • Vous voulez vos jobs CI, vos crons et vos scripts dans la même vue de santé que votre cluster.
  • Vous préféreriez ne pas héberger — ni surveiller séparément — votre propre monitoring.

Ou les deux

Faire tourner les deux est un montage raisonnable, pas un compromis. Uptime Kuma répond à « est-ce que mon client arrive à m'atteindre ? », depuis l'extérieur de votre réseau. Sentinel répond à « est-ce que ça va, là-dedans ? », et sait le dire avant que l'endpoint s'éteigne. Tout ce qui parle HTTP peut pousser vers Sentinel à côté de votre cluster, donc la CI, les crons et les scripts arrivent sur la même frise.

anything that speaks HTTP

curl -X POST https://app.sentinel-app.io/api/v1/signals/ \
  -H "Content-Type: application/json" \
  -H "STNL-Access-Key: $KEY_ID" \
  -H "STNL-Secret-Key: $SECRET" \
  -d '{"service": "nightly-etl", "status": 1}'

Les questions qu'on nous pose vraiment

Uptime Kuma peut-il surveiller des workloads Kubernetes ?

Seulement indirectement, en checkant une URL servie par le workload. Il ne peut pas voir que 2 réplicas sur 3 sont prêts, qu'un nœud est sous pression mémoire, ou qu'un rollout n'a jamais convergé — rien de tout ça n'apparaît sur un check HTTP avant qu'il soit déjà trop tard.

Sentinel est-il open source comme Uptime Kuma ?

L'opérateur Kubernetes l'est. Le backend ne l'est pas — c'est le service hébergé qui finance le développement. Si auto-héberger toute la stack est pour vous une exigence ferme, Uptime Kuma est le choix le plus honnête.

Puis-je garder les deux ?

Oui, et beaucoup d'installations devraient : Kuma pour la disponibilité vue de l'extérieur, Sentinel pour ce qui se passe à l'intérieur du cluster et pour tout le reste qui pousse des signaux.

Des tarifs simples et transparents

Gratuit pour commencer. Évoluez selon vos besoins.