SolidPing vs Kener
Si la page de statut publique est ce qui compte le plus pour vous, prenez Kener. C'est d'abord un système de pages de statut, avec une supervision intégrée pour les alimenter, et ses pages sont plus personnalisables que les nôtres : thèmes, CSS et JavaScript personnalisés, plusieurs pages par instance, intégrations, badges et RSS. Son README dit qu'il n'est pas là pour remplacer Datadog ou Atlassian, et il est honnête là-dessus.
SolidPing est d'abord un outil de supervision. Il a des pages de statut, mais son poids est sur les types de check, les checks multi-régions, les alertes et l'astreinte.
Kener est développé par Raj Nandan Sharma, sous licence MIT. Les informations ci-dessous viennent de son dépôt et de la documentation qu'il contient au 6 octobre 2026 (v4.1.6). Le projet publie souvent. Si nous nous sommes trompés sur un détail, merci d'ouvrir un ticket.
En un coup d'œil
| SolidPing (auto-hébergé) | Kener | |
|---|---|---|
| Licence | AGPL-3.0 | MIT |
| Stack | Un binaire Go | SvelteKit et Node.js (24.14 ou plus récent) |
| Base de données | SQLite ou PostgreSQL | SQLite, PostgreSQL ou MySQL |
| Autres services | Aucun | Redis obligatoire |
| Types de check | 40, dont UDP, SMTP, IMAP, SSH, FTP, WebSocket, Kafka, MQTT, SNMP, sept bases de données et des checks navigateur | 12 : API, Ping, TCP, DNS, SSL, SQL, Heartbeat, GameDig, gRPC, Docker, Prometheus, Group |
| Planification | Jusqu'à 10 secondes | Une expression cron par moniteur |
| Multi-régions | Workers et agents privés où vous voulez | Non documenté. Les checks partent du serveur Kener |
| Canaux d'alerte | E-mail, Slack, Discord, Teams, Telegram, ntfy, PagerDuty, Matrix, Pushover, webhooks et d'autres ; SMS et appels via votre propre Twilio | Webhook, Discord, Slack, e-mail |
| Astreinte et escalade | Rotations, remplacements, escalade en plusieurs étapes | Non |
| Pages de statut | Publiques, sections, domaines personnalisés, abonnés | Plusieurs pages, thèmes, CSS et JS personnalisés, i18n, intégrations, badges, RSS |
| Abonnés | Oui | E-mail, vérifié par code, préférences par type d'événement |
| Maintenance | Fenêtres de maintenance | Maintenance avec récurrence RRULE |
| Utilisateurs et SSO | Organisations, rôles, OIDC, SAML, LDAP, Google, GitHub, GitLab, Microsoft | Rôles admin, éditeur, membre et personnalisés ; OIDC avec correspondance groupe-rôle |
| Offre hébergée | SolidPing Cloud | Aucune |
| Automatisation | API REST, CLI sp, YAML apply, serveur MCP | API REST avec clés d'API |
Là où Kener est le meilleur choix
La page de statut publique. Thèmes, CSS et polices personnalisés, plusieurs pages, widgets intégrables et RSS. C'est le cœur du produit et ça se voit.
Abonnés et maintenance. Abonnements e-mail vérifiés par code avec préférences par événement, et maintenance récurrente en RRULE.
Des rôles personnalisés. Permissions fines et correspondance des groupes OIDC vers les rôles.
MySQL. Si MySQL est votre base maison, Kener tourne dessus. SolidPing non.
Là où SolidPing est le meilleur choix
Les types de check. 40 contre 12. Serveurs mail, files de messages, SSH, FTP, SNMP et d'autres ont des checks dédiés.
Alertes et astreinte. Beaucoup plus de canaux, plus les rotations et l'escalade. Kener a quatre canaux et pas d'astreinte.
Des checks depuis plusieurs endroits. SolidPing fait tourner des workers et des agents privés où vous les placez. Kener vérifie depuis le seul serveur où il tourne.
Moins de pièces. Un binaire sur SQLite. Kener a besoin de Node.js et d'un Redis.
Une offre hébergée. SolidPing Cloud fait tourner le même binaire, avec une offre gratuite de 100 moniteurs. Kener est uniquement auto-hébergé.
Lequel choisir ?
Prenez Kener quand la page de statut est le livrable et qu'une poignée de moniteurs depuis un seul endroit suffit.
Prenez SolidPing quand la supervision et les alertes sont le sujet et que la page de statut n'en est qu'une partie. SolidPing n'a pas d'import Kener : migrer veut dire recréer les moniteurs via le tableau de bord, l'API ou un fichier YAML.