OpenStatus : un nouveau dashboard qui muscle le monitoring open-source

Je vous avais parlé d’OpenStatus comme d’une pépite open source pour monitorer vos sites/API et publier une page de statut sans livrer vos métriques à un SaaS glouton. Les devs viennent d’annoncer une grosse refonte du dashboard avec un billet qui porte bien son nom : We Are So Back.
Au menu : nouvelle navigation, nouveaux graphiques utiles (pas des donut charts pour faire joli), timeline d’événements, et un template shadcn/Next.js offert pour vous inspirer côté UI. Et surtout, même pricing… mais plus de moniteurs inclus. Oui, pour une fois, on ne vous tord pas le bras.

La refonte passe d’un header en onglets à une sidebar qui liste vos status pages et moniteurs avec leur état (actif, dégradé, en erreur). Plus lisible, plus rapide pour enchaîner les edits, et un breadcrumb en haut pour circuler entre sous-pages. Cerise sur le gâteau : un panneau latéral droit “à la demande” balance des infos contextuelles sans vous noyer. Les incidents quittent la nav principale pour vivre dans chaque moniteur, logique quand on ne prétend pas devenir un outil d’astreinte complet mais s’intégrer avec ceux que vous aimez déjà. Propre.

Côté observabilité utile, ils ajoutent une Timeline appuyée par leurs audit_logs Tinybird (origine des pannes par région, notifications envoyées, moments de dégradation). Trois éléments visuels nouveaux font la différence au quotidien :

• un Timing Phase Area Chart (DNS, TTFB, transfert, etc. par région),
• un Uptime Bar Chart plus granulaire (avec volume de pings),
• une Degraded Overview Card qui met en lumière les lenteurs sournoises — celles qui flinguent l’expérience sans déclencher d’alarme “DOWN”.
  Fini les “tout va bien chez nous” alors que vos utilisateurs pleurent.

Le mouvement “Stop au ClickOps, vive le GitOps” s’accélère avec la CLI OpenStatus. Vous pouvez importer vos moniteurs depuis l’UI vers un YAML versionné, appliquer des changements et déclencher des checks depuis vos workflows. Pour l’installer :

brew tap openstatus/cli && brew install openstatus
openstatus monitors import
openstatus monitors apply

Ils détaillent aussi l’intégration GitHub Action pour des tests synthétiques post-déploiement. Vous gardez l’historique des modifs, vous reliez infra et monitoring comme des adultes.

Petit bonus qui fera plaisir aux front lovers : un template shadcn x Next.js offert, avec des composants (form-card, metric-card, empty-state, etc.) installables via la CLI shadcn. Idéal pour piocher des patterns et accélérer vos propres dashboards internes. Là aussi, open bar.

Et le pricing ? Les auteurs l’annoncent eux-mêmes : “Same Pricing. More Monitors.” Le détail des paliers est sur la page tarifs, mais l’esprit est clair : le ticket d’entrée ne bouge pas, la capacité grimpe. Pour une boîte qui pousse une alternative open et transparente, c’est cohérent.

Maintenant, parlons franchement self-host. Oui, OpenStatus est open source et auto-hébergeable, mais ce n’est pas encore trivial : la doc le dit noir sur blanc, une community edition plus simple est prévue. Vous pouvez déjà faire tourner le stack en dev, déployer le checker en conteneur dans votre infra, et bosser votre Monitoring as Code proprement. Si vous voulez du “one-click Docker tout de suite”, regardez Uptime Kuma en parallèle : c’est moins ambitieux côté multi-régions/OTel, mais super simple à poser. À vous de choisir entre souplesse, portée globale et facilité immédiate.

Vous voulez tester vite fait sans vendre votre âme ? Voici un démarrage minimal (sans toute la conf) pour jouer en local et sentir la bête :

# 1) Cloner et lancer en dev
git clone https://github.com/openstatusHQ/openstatus.git
cd openstatus
pnpm install
# Base libSQL/Turso locale
turso dev --db-file openstatus-dev.db
# Lancer l'app
pnpm dx && pnpm dev:web  # http://localhost:3000

# 2) Installer la CLI (Mac/Linux via Homebrew)
brew tap openstatus/cli
brew install openstatus

# 3) Passer au Monitoring-as-Code
openstatus monitors import > config.openstatus.yaml
# ...éditer le YAML...
openstatus monitors apply -f config.openstatus.yaml

Comme toujours pour la prod, prévoyez votre reverse proxy, la persistance, vos secrets, et vos régions cibles (35 dispo côté cloud).

Mon verdict après cette release : OpenStatus consolide là où ça compte — lisibilité, investigabilité, infra-as-code — sans céder à la boulimie de features. Ça reste un très bon candidat pour celles et ceux qui veulent garder la main sur leurs données de monitoring et publier une status page claire, le tout avec un workflow Git-friendly. Et oui, je préfère ça à un SaaS opacifié qui pompe vos logs sans vous embrasser.

Source