Documentation Pinguro

Introduction

Pinguro est un service de monitoring à destination des indépendants, petites équipes et agences qui gèrent plusieurs sites. Il surveille quatre types de cibles — HTTP/HTTPS, DNS, ports TCP, heartbeats (jobs cron) — à intervalle régulier (intervalle minimum de 1 à 15 min selon le plan), détecte les pannes et vous alerte sur le canal de votre choix.

Les choix clés de Pinguro : un dashboard dense sans être surchargé, une configuration lisible (pas d'assistants à 7 étapes), des alertes fiables (en cas d'erreur réseau passagère, un nouvel essai est fait 2 secondes plus tard avant de déclarer la panne), une status page publique à créer en quelques clics, et une API REST pour automatiser (plans payants).

Créer son premier monitor

1. 1
   Depuis le dashboard

   Cliquez sur + Ajouter un monitor en haut à droite de la section Monitors.

2. 2
   Renseignez les champs

   Un nom lisible (ex. Site vitrine Acme), l'URL complète avec protocole (https://…), puis l'intervalle de check : 1, 5 ou 15 minutes (15 minutes sur le plan Free). Une panne est donc détectée au plus tard un intervalle après son début, soit jusqu'à 15 minutes sur le plan Free. Pour répartir la charge, chaque vérification peut avoir lieu jusqu'à 10 % plus tôt que l'intervalle choisi, jamais plus tard : un monitor réglé sur 1 minute est vérifié toutes les minutes, même quand le site met du temps à répondre.

3. 3
   Assignez un groupe (optionnel)

   Si vous gérez plusieurs clients, créez d'abord un groupe coloré, puis rattachez le monitor. Facultatif — on démarre très bien sans. Les groupes sont réservés aux plans Solo et au-delà (pas encore commercialisés).

4. 4
   Enregistrez

   Le premier check part dans la minute qui suit. Le statut apparaît dans la liste des monitors ; le temps de réponse et la disponibilité (24 h, 7 j, 30 j) sont sur la page détail du monitor.

Types de monitor

À la création, choisissez parmi quatre types selon ce que vous surveillez :

HTTP / HTTPS (par défaut)

Pinguro envoie une requête HTTP à l'URL et vérifie le code, le corps, le certificat SSL. C'est le choix usuel pour un site, une API, un endpoint /health.

DNS

Pinguro résout un nom de domaine et vérifie que l'enregistrement attendu est présent. Détecte un hijacking ou un failover DNS défaillant. Voir DNS monitoring.

TCP / Port

Pinguro ouvre une connexion TCP sur un host + port donnés. Pratique pour SMTP, SSH, PostgreSQL, Redis — tout service non-HTTP. Voir TCP / Port.

Heartbeat

Monitoring inversé : c'est votre job (cron, CI, batch) qui ping Pinguro. Sans signal dans la fenêtre attendue + délai de grâce, vous êtes alerté. Voir Heartbeat / Cron.

DNS monitoring

Surveille qu'un nom de domaine résout bien vers l'enregistrement attendu. Cas d'usage : détection de hijacking, validation d'un failover DNS, contrôle de la propagation après changement de registrar.

Configuration

• Hostname — le nom à résoudre, sans schéma ni chemin (ex. acme.com, mx.acme.com).
• Type d'enregistrement — l'un de A, AAAA, MX, CNAME, TXT.
• IPs attendues (records A / AAAA uniquement) — liste d'IPs. Si elle n'est pas vide, il suffit qu'au moins une des IPs retournées figure dans la liste. Maximum 20.

Comment ça marche

À chaque check, Pinguro interroge le résolveur DNS de son serveur (délai de 5 secondes, avec un nouvel essai en cas d'échec) et compare le résultat à votre configuration :

• Pour A et AAAA avec IPs attendues : alerte si la résolution échoue ou si aucune des IPs retournées ne figure dans la liste.
• Pour A et AAAA sans IPs attendues : alerte uniquement si la résolution échoue (au moins une IP doit être retournée).
• Pour MX, CNAME, TXT : alerte si la résolution échoue ou renvoie un résultat vide.

Exemples

• Apex vers Cloudflare — type A, IPs attendues 104.21.x.x et 172.67.x.x.
• MX Google Workspace — type MX, sans IPs attendues (on vérifie juste qu'au moins un MX est publié).
• Record TXT SPF — type TXT, détecte la disparition accidentelle après reconfiguration.

TCP / Port

Vérifie qu'un port répond, sans aucune hypothèse applicative. Pinguro ouvre un socket TCP, note si le handshake réussit dans un délai de 5 secondes (avec un nouvel essai en cas d'échec), puis ferme. Aucun payload n'est envoyé.

Configuration

• Host — hostname ou IP (pas de schéma, pas de chemin).
• Port — entier entre 1 et 65535.

Cas d'usage courants

SMTP

Ports 25 (relay), 587 (submission), 465 (legacy). Vérifie que votre serveur mail accepte des connexions.

SSH

Port 22 (ou custom). Utile pour un bastion ou un serveur de build.

PostgreSQL / MySQL / Redis

Ports 5432 / 3306 / 6379. Check de joignabilité de la base — complémentaire d'un check applicatif HTTP.

Gateway applicatif / jeu en ligne

N'importe quel port custom où l'outillage HTTP n'est pas pertinent.

Heartbeat / Cron

Monitoring inversé : contrairement aux autres types, c'est votre code qui ping Pinguro, pas l'inverse. Si le ping n'arrive pas dans la fenêtre attendue + le délai de grâce, vous recevez une alerte. Idéal pour :

• Un cron de backup nocturne — savoir si la sauvegarde a bien tourné, pas juste si le serveur est up.
• Un pipeline CI ou un script planifié.
• Un batch applicatif (envoi de digest, réconciliation, nettoyage de tables).

Configuration

• Identifiant — un nom libre (ex. nightly-backup). Pas une URL.
• Intervalle attendu — fréquence à laquelle votre job doit pinger. De 1 minute à 43200 minutes (30 jours), sur tous les plans : l'intervalle minimum du plan ne s'applique pas aux heartbeats.
• Délai de grâce — combien de temps on tolère un retard avant d'alerter. 0 à 1440 minutes (défaut 5 min). Avec 0, l'alerte part dans la minute qui suit le dépassement de l'intervalle attendu.

Pinguro génère un token unique à la création. L'URL de ping est https://pinguro.app/h/<TOKEN>. Elle accepte GET ou POST, dans la limite de 10 pings par minute et par token.

Un heartbeat qui n'a jamais reçu de ping passe DOWN 24 heures après sa création : ce délai vous laisse le temps de brancher votre job.

Exemple cron Unix

# Backup nocturne à 3h — on ping Pinguro si et seulement si le script a réussi
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://pinguro.app/h/VOTRE_TOKEN > /dev/null

Le && est volontaire : on ne ping que si backup.sh termine avec code 0. En cas d'échec, Pinguro ne reçoit rien, le délai s'écoule, l'alerte part.

Les flags -fsS de curl : -f fait retourner un code erreur sur HTTP 4xx/5xx, -s silence la progression, -S garde l'affichage d'erreur. Pratique dans un cron.

Exemple Python

import requests, sys

def main():
    # ... votre logique métier ...
    print("job terminé")

try:
    main()
    # Ping uniquement en cas de succès
    requests.get("https://pinguro.app/h/VOTRE_TOKEN", timeout=10)
except Exception as e:
    print("échec :", e, file=sys.stderr)
    sys.exit(1)

Exemple GitHub Actions

- name: Notify Pinguro heartbeat
  if: success()
  run: curl -fsS "https://pinguro.app/h/${{ secrets.PINGURO_HEARTBEAT_TOKEN }}"

Options avancées (HTTP)

Plans Solo et au-delà (pas encore commercialisés). Sur le plan Free, un monitor HTTP utilise la méthode GET et accepte les codes 200–299.

Les monitors HTTP/HTTPS exposent une section Configuration avancée repliable. Voici ce que fait chaque option :

Méthode HTTP

GET par défaut. HEAD est utile pour économiser la bande passante sur des gros fichiers mais ne lit pas le corps (incompatible avec la surveillance du contenu). POST pour vérifier un endpoint qui requiert POST — le corps n'est pas paramétrable pour l'instant.

Plage de codes HTTP acceptés

Par défaut 200–299. Les redirections (3xx) sont suivies automatiquement (5 au maximum) : la plage s'applique au code de la page finale. Resserrez à 200–200 pour exiger un OK strict.

Mot-clé (keyword)

Doit contenir alerte si le texte est absent du corps de la réponse (ex. le mot OK dans un endpoint /health). Ne doit PAS contenir alerte si un mot-clé indésirable apparaît (ex. Erreur 500). La recherche est sensible à la casse et porte sur les 256 premiers Ko du corps. 500 caractères maximum. Ignoré avec la méthode HEAD.

Headers HTTP (JSON)

Objet JSON de headers à envoyer à chaque check. Pratique pour une clé API ou un User-Agent personnalisé : {"X-API-Key": "secret"}. Les valeurs doivent être des chaînes de caractères. 10 headers maximum ; Host, Content-Length et Connection sont interdits, de même que les noms avec espace et les valeurs avec retour à la ligne.

Vérification SSL

Active l'alerte d'expiration du certificat (URL en https:// requise). Vous recevez une alerte quand il reste 7 jours ou moins, répétée chaque jour jusqu'au renouvellement. Repose sur la date notAfter du certificat — pas de vérification de révocation (OCSP). Même sans cette option, un certificat expiré ou invalide fait passer le monitor DOWN.

Groupes

Plans Solo et au-delà (pas encore commercialisés).

Les groupes organisent vos monitors par projet, client, ou environnement. Chaque groupe a un nom et une couleur (badge visible dans la liste des monitors).

• Free : pas de groupe. Solo : jusqu'à 10. Agency et Enterprise : illimité.
• Un monitor appartient à 0 ou 1 groupe.
• Supprimer un groupe ne supprime pas ses monitors — ils retombent simplement dans Sans groupe.
• L'ordre dans l'UI est alphabétique.
• Chaque groupe a son réglage de regroupement des alertes : comme le workspace, toujours regrouper, ou jamais (alerte immédiate).

Workspaces

Un workspace est un espace de monitoring isolé. Chaque workspace contient ses propres monitors, groupes, canaux d'alerte, status page, clés API et fenêtres de maintenance. Vous pouvez appartenir à plusieurs workspaces (par exemple un workspace perso et un workspace partagé avec votre équipe), et basculer de l'un à l'autre via le sélecteur en haut de la sidebar.

Cas d'usage typiques

• Séparer perso et travail : un workspace pour vos sites perso, un autre pour les sites de votre entreprise. Les alertes du travail ne polluent pas votre Telegram perso.
• Gérer des clients (agence web) : un workspace par client, ou un seul workspace de travail avec des groupes par client. Le routage par groupe (voir Canaux d'alerte) permet alors d'envoyer les alertes de chaque client vers sa propre destination Discord ou email.
• Partager avec un collègue : vous invitez un collègue dans un workspace ; il ne voit pas vos autres workspaces. À l'inverse, il peut avoir son propre workspace perso où vous n'êtes pas.

Posséder plusieurs workspaces (plan Agency et au-delà) et inviter des membres (plan Solo et au-delà) nécessitent un plan payant, pas encore commercialisé.

Créer, renommer, supprimer

Le sélecteur en haut de la sidebar liste vos workspaces. Cliquez dessus pour ouvrir le menu (les mêmes actions sont disponibles sur la page Workspaces) :

• + Nouveau workspace : crée un workspace dont vous devenez le propriétaire (owner), dans la limite de votre plan.
• ✎ à côté d'un workspace : le renomme (réservé à l'owner et aux admins).
• 🗑 à côté d'un workspace : le supprime (réservé à l'owner). La suppression de votre dernier workspace est refusée — il en faut au moins un.
• Les workspaces où vous êtes invité (sans en être l'owner) affichent un badge partagé.

Limites par plan utilisateur

Le nombre de workspaces dont vous pouvez être propriétaire dépend de votre plan personnel :

• Free : 1 workspace propriétaire
• Solo : 1 workspace propriétaire
• Agency : jusqu'à 3 workspaces propriétaires
• Enterprise : illimité

Vous pouvez en revanche être membre (invité) d'autant de workspaces que vous le souhaitez, sans limite. Le plan (Free / Solo / Agency / Enterprise) est celui du compte propriétaire : ses limites (nombre de monitors, groupes, clés API, membres, intervalle minimum, canaux d'alerte avancés, etc.) s'appliquent à l'ensemble des workspaces qu'il possède, tous confondus.

Migration depuis l'ancien modèle

Si vous utilisiez Pinguro avant l'arrivée des workspaces, tous vos monitors, groupes, canaux d'alerte et autres ressources existants ont été conservés dans votre workspace par défaut (renommable). Aucune perte de données. Vous pouvez ensuite créer de nouveaux workspaces et choisir où placer les nouvelles ressources.

Fenêtres de maintenance

Planifiez à l'avance une fenêtre sans alertes — par exemple pour un déploiement, une migration de base, ou une intervention chez un hébergeur. Pendant la fenêtre, les checks continuent mais les alertes sont supprimées et les minutes d'indisponibilité ne comptent pas dans le SLA.

Configuration

• Titre — ce qui sera affiché dans l'historique et sur la status page publique.
• Début / fin — horodatage précis à la minute, saisi dans le fuseau horaire de votre navigateur.
• Monitors concernés — Tous mes monitors, ou une Sélection explicite.

Effets pendant la fenêtre

• Aucune alerte (email, Slack, Discord, Telegram, webhook) n'est envoyée pour les monitors dans le scope.
• Les heartbeats attendus pendant la fenêtre ne déclenchent pas d'alerte en cas de ping manquant.
• La status page affiche un bandeau Maintenance en cours pendant la fenêtre, et Maintenance prévue pour une fenêtre à venir dans les 7 prochains jours.
• Les rapports SLA excluent les minutes de la fenêtre du calcul de disponibilité.

Accessible à tous les plans

Pas de restriction par plan. Chaque compte peut enregistrer jusqu'à 100 fenêtres de maintenance, fenêtres passées comprises, tous workspaces confondus.

Statuts et types de panne

Pinguro distingue plusieurs états de monitor pour vous aider à comprendre ce qui se passe :

UP — opérationnel

La cible répond correctement (code HTTP attendu, mot-clé présent, DNS résolu, port TCP ouvert, ping reçu dans le délai). Aucune alerte.

LENT — réponse lente (orange)

Le badge "LENT" couvre deux situations distinctes :

• Timeout : la cible n'a pas répondu dans les 10 secondes (délai appliqué à chaque requête, redirections comprises), puis n'a pas répondu non plus au nouvel essai, plus court (8 secondes au total), fait 2 secondes plus tard. Le monitor passe DOWN avec la raison timeout. Compté comme downtime côté SLA.
• Lent mais UP : la cible a répondu, mais au-delà du seuil que vous avez configuré sur le monitor (Seuil "lent"). Le monitor reste UP. Compté comme uptime côté SLA.

Dans les deux cas, le badge orange identique permet de repérer rapidement un service en difficulté.

DOWN — panne réelle (rouge)

La cible a refusé la connexion, renvoyé un code HTTP hors de la plage attendue (un 404 ou un 5xx, par exemple), échoué la vérification du mot-clé, échoué la résolution DNS, ou autre erreur "dure". Différent de "lent" — ici le service ne fonctionne pas comme attendu.

MODIFIÉ — contenu modifié

La surveillance du contenu a détecté un changement de la page. Le site répond, mais un incident « contenu modifié » reste ouvert jusqu'à ce que vous cliquiez sur Réinitialiser.

En pause

Le monitor est désactivé : aucune vérification ni alerte. Un monitor en pause ne compte pas dans la limite de monitors de votre plan, ni dans la limite de 50 monitors actifs par domaine.

Marquer un monitor "lent" (SLOW)

Un site qui répond en 5 secondes est techniquement UP, mais c'est souvent le signe qu'il faut investiguer (cache vide, base de données surchargée, hébergement à la peine). Pinguro permet de configurer un seuil "lent" par monitor pour visualiser ces dégradations sans qu'elles soient comptabilisées comme du downtime.

Depuis l'édition du monitor, section Performance :

• Seuil "lent" : nombre de millisecondes au-delà duquel la réponse est considérée lente (200 à 30 000 ms, ou vide pour désactiver). Exemple : 3000 ms = badge orange "LENT" si la réponse dépasse 3 secondes.
• M'alerter si le site répond plus lentement que ce seuil : si cette case est cochée, vous recevez une notification quand le monitor entre en zone "lent" et une autre quand il en sort (anti-spam — pas une alerte par check). Désactivé par défaut.

Le statut SLOW ne dégrade pas l'uptime : le site répond, donc il est compté comme UP dans le calcul du SLA. C'est une métrique purement visuelle pour repérer les ralentissements en avance.

Désactiver les alertes timeout sur un monitor

Si vous surveillez un site régulièrement lent (cache vide, hébergeur partagé, etc.), vous pouvez désactiver les notifications de timeout pour ce monitor sans perdre la mesure d'uptime : depuis l'édition d'un monitor HTTP, section Notifications, décochez « M'alerter si le site est totalement injoignable (timeout = panne) ». Cette option n'existe que pour les monitors HTTP.

Dans ce cas :

• L'incident est quand même enregistré dans l'historique et apparaît sur la status page.
• Le monitor passe quand même DOWN et compte comme downtime dans le SLA.
• Mais aucune alerte (email, Slack, Discord, Telegram, webhook) n'est envoyée pour ce timeout précis.

Les autres types de DOWN (code HTTP hors plage, connexion refusée, etc.) continuent de déclencher les alertes normalement.

Canaux d'alerte

Configurez un ou plusieurs canaux depuis Alertes dans la sidebar. Chaque canal peut être mis en pause individuellement (toggle) sans être supprimé. Les canaux sont liés au workspace actif : un workspace ne voit que ses propres canaux.

Ces canaux reçoivent aussi les messages envoyés par vos propres scripts (sauvegarde, tâche planifiée, déploiement) : voir Notifications par API.

Routing par groupe

Plans Solo et au-delà (pas encore commercialisés), car il repose sur les groupes.

Par défaut, un canal d'alerte reçoit toutes les alertes des monitors du workspace. Vous pouvez affiner ce comportement en éditant un canal et en passant le mode de routage à Certains groupes uniquement, puis en cochant les groupes concernés.

Cas typique pour une agence web : un workspace "Client A" contient les groupes "Boutique", "Blog", "Outils internes". Vous pouvez alors avoir :

• Un Discord Sites publics qui reçoit uniquement les groupes "Boutique" + "Blog"
• Un Discord Outils qui reçoit uniquement le groupe "Outils internes"
• Un email Astreinte qui reçoit tout (mode Tous les monitors du workspace)

Note : un canal en mode groupes ne reçoit pas les alertes des monitors qui ne sont dans aucun groupe (sans groupe = jamais routé). C'est volontaire : un canal ciblé n'a pas de raison de recevoir des monitors non-classés.

Pourquoi mon alerte arrive-t-elle quelques minutes après la panne ?

Une panne est d'abord détectée au rythme des vérifications de votre monitor, puis confirmée (en cas d'erreur passagère comme un délai dépassé, un second essai est fait avant de déclarer le site DOWN, pour éviter les fausses alertes). Ensuite, tout dépend du réglage Regroupement des alertes :

• Sans regroupement — l'alerte part dès que la panne est confirmée, lors de la vérification qui la détecte : le délai dépend donc de l'intervalle du monitor (jusqu'à 15 minutes sur le plan Free).
• Avec regroupement — l'alerte attend environ 2 minutes de plus. Si au moins 3 sites tombent quasiment en même temps (typiquement une panne d'hébergeur qui touche 60 sites d'un coup), vous recevez un seul message qui les liste tous, au lieu de 60. En dessous de 3, chaque panne arrive en message normal, simplement avec ce petit délai.

Le réglage se fait à deux niveaux :

• Par workspace — sur la page Workspaces, interrupteur Regroupement des alertes (modifiable par le propriétaire et les admins). Il s'applique à tous les monitors du workspace, y compris ceux sans groupe. Un nouveau workspace démarre sans regroupement : alertes immédiates.
• Par groupe (plans Solo et au-delà, pas encore commercialisés) — à la création ou à l'édition d'un groupe : Comme le workspace (par défaut), Toujours regrouper ou Jamais — alerte immédiate. Pratique pour regrouper un parc de sites hébergés au même endroit tout en gardant l'alerte immédiate pour un client sensible.

Le regroupement se fait groupe par groupe, à partir de 3 monitors tombés quasiment en même temps : si deux groupes tombent en même temps, chacun reçoit son propre message, jamais un mélange des deux. Les monitors sans groupe sont regroupés entre eux. Les retours à la normale (UP) suivent la même règle que les pannes.

Si l'envoi d'une alerte de panne (DOWN) ou de retour à la normale (UP) échoue vers un canal email, Slack, Discord ou Telegram (par exemple un serveur email momentanément indisponible), l'alerte n'est pas perdue : elle est réessayée automatiquement vers ce canal, avec des essais de plus en plus espacés (de quelques minutes à une heure au plus entre deux essais), pendant 24 h au plus après la panne ou le retour à la normale. Au-delà (par exemple une adresse de webhook Slack ou Discord supprimée), ce canal est abandonné pour cette alerte. Les canaux qui l'ont déjà reçue ne la reçoivent pas une seconde fois. Les webhooks et les alertes SSL, LENT et contenu modifié ne sont pas renvoyés en cas d'échec. Les webhooks ne sont jamais regroupés : ils partent toujours immédiatement, un par monitor.

Email

Canal par défaut, créé automatiquement à l'inscription vers l'adresse du compte, dans votre premier workspace uniquement : dans un nouveau workspace, ajoutez vous-même un canal. Vous pouvez en ajouter d'autres pour alerter plusieurs personnes. Seul canal disponible sur le plan Free.

Confirmation des adresses. Une adresse qui n'est ni celle de votre compte ni celle d'un membre du workspace doit être confirmée par son destinataire : à l'ajout du canal (ou quand vous changez son adresse), il reçoit un email « Confirmez la réception des alertes Pinguro » avec un lien valable 7 jours, qui permet de confirmer ou de refuser, sans compte. Tant que l'adresse n'est pas confirmée, aucune alerte ne lui est envoyée (le bouton Tester est aussi bloqué) ; vos autres canaux reçoivent normalement. Dans Alertes, chaque canal email affiche En attente de confirmation, Confirmée ou Désinscrite ; le bouton Renvoyer envoie un nouveau lien, dans la limite de 3 emails de confirmation par 24 heures pour une même adresse. Une adresse déjà confirmée sur un autre canal du même workspace n'a pas à l'être de nouveau. Les canaux créés avant la mise en place de cette confirmation sont considérés comme confirmés.

Les alertes envoyées à une adresse tierce confirmée contiennent un lien Ne plus recevoir ces alertes : son destinataire peut se désinscrire en un clic, sans compte, de tous les canaux du workspace qui visent son adresse. L'adresse apparaît alors comme Désinscrite et ne reçoit plus rien. Il en va de même si le destinataire refuse depuis l'email de confirmation. Une adresse désinscrite n'est plus sollicitée par ce workspace : même si vous recréez un canal vers elle, aucune demande de confirmation ne lui est envoyée.

Slack

Slack, Discord, Telegram et webhook : plans Solo et au-delà (pas encore commercialisés).

Créez un Incoming Webhook depuis votre espace Slack (Apps → Incoming Webhooks → Add to Slack). Copiez l'URL en https://hooks.slack.com/services/… dans Pinguro.

Discord

Dans votre serveur : Paramètres du salon → Intégrations → Webhooks → Nouveau webhook. Copiez l'URL en https://discord.com/api/webhooks/….

Telegram

Pour recevoir les alertes Pinguro sur Telegram, vous avez besoin de deux valeurs : un bot_token (identifiant de votre bot) et un chat_id (destination des messages). Suivez la procédure ci-dessous.

1. 1
   Créer le bot

   Ouvrez Telegram et cherchez @BotFather. Démarrez une conversation.

2. 2
   Envoyer /newbot

   Suivez les instructions de BotFather et choisissez un nom pour votre bot, puis un username terminant par bot.

3. 3
   Récupérer le bot token

   BotFather vous renvoie un token au format 123456:ABC-xxxxx — c'est votre bot_token.

   Attention. Ne partagez jamais ce token : il permet d'envoyer des messages au nom de votre bot.
4. 4
   Activer la conversation

   Cherchez votre bot dans Telegram par son nom d'utilisateur. Cliquez sur Démarrer pour activer la conversation. Sans cette étape, le bot ne peut pas vous envoyer de message.

5. 5
   Ouvrir l'endpoint getUpdates

   Dans votre navigateur, ouvrez (remplacez <TOKEN> par votre bot token) :

   https://api.telegram.org/bot<TOKEN>/getUpdates

6. 6
   Récupérer le chat_id

   Dans la réponse JSON, trouvez le champ "chat": { "id": XXXXX } — c'est votre chat_id.

   Canal ou groupe. Pour un canal ou un groupe, le chat_id est négatif (ex. -100123456789). Ajoutez d'abord le bot au groupe/canal, puis renvoyez un message pour qu'il apparaisse dans getUpdates.
7. 7
   Configurer dans Pinguro

   Dans Pinguro, créez un canal Telegram. Collez l'URL complète de sendMessage :

   https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<CHAT_ID>

   (remplacez <TOKEN> par votre bot_token et <CHAT_ID> par votre chat_id).

   Astuce. Si vous utilisez déjà cette URL dans un autre outil, vous pouvez simplement la copier-coller.

Webhook générique

Pour brancher Pinguro sur n'importe quel service qui accepte du JSON. L'URL doit commencer par https://. Pinguro envoie en POST le payload suivant sur votre URL :

{
  "event": "down",
  "type": "down",
  "monitor": {
    "id": 42,
    "name": "Site vitrine Acme",
    "url": "https://acme.com",
    "group_id": 7,
    "organization_id": 3
  },
  "reason": "status_out_of_range",
  "reason_label": "Code HTTP 404 (attendu 200–299)",
  "http_status": 404,
  "timestamp": 1776522067000
}

Les évènements possibles sont down, up, ssl_expiring, content_changed, slow_detected et slow_recovered. L'objet monitor contient toujours group_id (null sans groupe) et organization_id (le workspace). Pour ssl_expiring, il contient aussi days_left (jours avant expiration) ; pour content_changed, le champ diff_percent (variation de taille en %) est présent à la racine et dans monitor ; pour slow_detected et slow_recovered, monitor contient slow_threshold_ms. Vous pouvez ajouter des headers personnalisés (ex. Authorization) dans la configuration du canal.

Votre URL doit répondre avec un code 2xx en moins de 10 secondes. Seules les redirections 307/308 qui restent sur le même domaine sont suivies (3 au maximum) : indiquez de préférence l'adresse finale. Ces règles valent aussi pour les webhooks Slack et Discord.

Pour un évènement down : reason est un code stable (ex. status_out_of_range, timeout_connect, keyword_not_found), reason_label sa description en français, et http_status le code HTTP reçu (null si le serveur n'a pas répondu). timestamp est en millisecondes depuis l'epoch Unix.

Webhooks signés (HMAC-SHA256)

Activez l'option Signer les requêtes sortantes pour que Pinguro signe chaque POST avec un secret partagé. Votre serveur peut alors vérifier que la requête provient bien de Pinguro et n'a pas été modifiée en transit, et rejeter les relectures d'anciens messages capturés.

À l'activation, Pinguro génère un secret au format whsec_<48 hex>, affiché une seule fois dans l'interface. Copiez-le immédiatement : il n'est plus récupérable après fermeture. Vous pouvez à tout moment le régénérer (Régénérer le secret) si vous soupçonnez une fuite — l'ancien secret cesse alors instantanément de valider les signatures.

En-têtes envoyés

X-Pinguro-Signature: t=1618365234,v1=a1b2c3...
X-Pinguro-Timestamp: 1618365234

Le champ t= est le timestamp Unix (secondes) de la requête, v1= est le HMAC-SHA256 hex de la chaîne `${timestamp}.${body}` avec votre secret. Le timestamp dans le header doit être utilisé pour la vérification (pas l'horloge serveur), afin que tous les champs signés soient explicites.

Tolérance temporelle recommandée : 300 secondes (5 minutes). Au-delà, rejetez la requête : un attaquant pourrait tenter de rejouer un vieux message capturé.

Exemple Node.js

const crypto = require('crypto');

function verifyPinguroSignature(headerValue, rawBody, secret, toleranceSeconds = 300) {
  if (!headerValue) return false;
  const parts = Object.fromEntries(headerValue.split(',').map(p => p.split('=')));
  if (!parts.t || !parts.v1) return false;
  const ts = Number(parts.t);
  if (!Number.isFinite(ts)) return false;
  if (Math.abs(Date.now() / 1000 - ts) > toleranceSeconds) return false;
  const expected = crypto.createHmac('sha256', secret)
    .update(`${ts}.${rawBody}`).digest('hex');
  if (expected.length !== parts.v1.length) return false;
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(parts.v1));
}

// Express : assurez-vous que le body brut est disponible
// app.use('/hook', express.raw({ type: 'application/json' }));
app.post('/hook', (req, res) => {
  const raw = req.body.toString('utf8');
  const ok = verifyPinguroSignature(req.headers['x-pinguro-signature'], raw, process.env.PINGURO_SECRET);
  if (!ok) return res.status(401).end();
  const payload = JSON.parse(raw);
  // ...
  res.status(200).end();
});

Exemple Python

import hmac, hashlib, time

# raw_body : le corps brut reçu, en bytes (ex. request.get_data() avec Flask)
def verify_pinguro_signature(header_value, raw_body, secret, tolerance_seconds=300):
    if not header_value:
        return False
    parts = dict(p.split('=', 1) for p in header_value.split(',') if '=' in p)
    t, v1 = parts.get('t'), parts.get('v1')
    if not t or not v1:
        return False
    try:
        ts = int(t)
    except ValueError:
        return False
    if abs(time.time() - ts) > tolerance_seconds:
        return False
    data = f"{ts}.".encode() + raw_body
    expected = hmac.new(secret.encode(), data, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, v1)

Exemple PHP

<?php
function verify_pinguro_signature($header, $rawBody, $secret, $tolerance = 300) {
  if (!$header) return false;
  $parts = [];
  foreach (explode(',', $header) as $p) {
    $kv = explode('=', $p, 2);
    if (count($kv) === 2) $parts[$kv[0]] = $kv[1];
  }
  if (empty($parts['t']) || empty($parts['v1'])) return false;
  $ts = (int)$parts['t'];
  if (abs(time() - $ts) > $tolerance) return false;
  $expected = hash_hmac('sha256', $ts . '.' . $rawBody, $secret);
  return hash_equals($expected, $parts['v1']);
}

Notifications par API

Tous les plans, y compris Free.

Un script — sauvegarde, tâche planifiée, déploiement, assistant de code — peut envoyer une notification (un titre, un message, un niveau) que Pinguro livre sur les canaux d'alerte du workspace : email, Slack, Discord, Telegram ou webhook, selon les canaux de votre plan (email uniquement sur Free). Pas besoin de clé API : chaque flux a sa propre URL secrète.

Créer un flux

• Ouvrez Notifications dans la sidebar, puis + Nouveau flux.
• Donnez-lui un nom (ex. Sauvegarde du serveur) et cochez les canaux qui doivent recevoir ses messages.
• Pour chaque canal, choisissez ce qu'il reçoit : Tout ; Succès, attention et erreurs ; Attention et erreurs ; Erreurs seulement. Les niveaux vont du moins au plus important : Info (info), Succès (success), Attention (warning), Erreur (error). Exemple : Telegram reçoit tout, l'email seulement les erreurs (chaque canal coché reçoit son propre exemplaire).
• L'URL du flux (https://pinguro.app/n/nfy_…) n'est affichée qu'une seule fois, à la création. Toute personne qui la connaît peut envoyer des notifications sur ce flux : gardez-la comme un mot de passe et ne la commitez pas dans un dépôt partagé. En cas de fuite, Régénérer l'URL désactive immédiatement l'ancienne.
• Un flux peut être désactivé (son URL répond alors 404) puis réactivé, ou supprimé. Envoyer un test envoie une notification d'essai sur ses canaux (10 tests par heure et par flux, comptés dans le quota du jour).
• Les membres en lecture seule (Viewer) voient les flux et l'historique, jamais l'URL. Créer, modifier, tester, régénérer, désactiver ou supprimer un flux demande le rôle Editor ou plus.

Envoyer une notification

POST sur l'URL du flux, en formulaire (pratique avec curl) ou en JSON :

curl -fsS -X POST "https://pinguro.app/n/VOTRE_JETON" \
  --data-urlencode "title=Déploiement terminé" \
  --data-urlencode "message=Nouvelle version en production" \
  -d level=success

curl -fsS -X POST "https://pinguro.app/n/VOTRE_JETON" \
  -H "Content-Type: application/json" \
  -d '{"title":"Déploiement en échec","message":"Étape build : code 2","level":"error"}'

• title — obligatoire, texte de 1 à 200 caractères.
• message — facultatif, texte de 4 000 caractères au plus (les retours à la ligne sont conservés).
• level — info (par défaut), success, warning ou error.
• Corps limité à 16 Ko. Tout autre champ est ignoré. Les caractères de contrôle et invisibles sont retirés. Le texte est affiché tel quel, sans mise en forme : ni HTML ni Markdown ne sont interprétés et aucun lien masqué ne peut être créé (une adresse écrite en clair peut toutefois rester cliquable dans la messagerie qui la reçoit).

Réponses

• 202 — notification acceptée : {"id": 123, "status": "accepted"}, ou "status": "merged" si elle répète un message identique récent (voir l'anti-boucle plus bas).
• 400 — champ invalide (la réponse indique le champ en cause dans field et un message dans error) ou corps illisible.
• 404 — URL inconnue, flux désactivé ou supprimé (même réponse dans tous les cas).
• 405 — méthode autre que POST.
• 413 — corps de plus de 16 Ko (ou formulaire de plus de 20 champs).
• 429 — quota du jour atteint, plus de 10 nouvelles notifications par minute sur le flux, ou plus de 120 appels par minute depuis la même adresse IP. L'en-tête Retry-After indique dans combien de secondes réessayer.

Limites

• Flux actifs par compte (tous workspaces confondus) : 1 (Free), 5 (Solo), 30 (Agency), 100 (Enterprise).
• Notifications par jour et par workspace : 30 (Free), 300 (Solo), 3 000 (Agency), 10 000 (Enterprise), selon le plan du propriétaire du workspace. Compteur remis à zéro chaque jour à minuit (UTC) ; la page Notifications affiche les envois du jour.
• 10 nouvelles notifications par minute et par flux.
• Anti-boucle : un message de même titre (casse et espaces ignorés) et de même niveau, reçu sur le même flux moins de 10 minutes après le premier message identique, n'est pas renvoyé ; l'historique affiche « ×N ». La fenêtre ne se prolonge pas à chaque répétition. Le message compte quand même dans le quota du jour.
• Après un passage à un plan inférieur, les flux au-delà de la limite (les plus récents) sont désactivés, pas supprimés : vous les réactivez à la main depuis la page Notifications, dans la limite du plan.

Livraison et historique

La notification est enregistrée puis envoyée aussitôt. Si un canal ne répond pas, Pinguro réessaie automatiquement au bout de 1, 5, 15, 30 et 60 minutes, puis toutes les heures, pendant 6 heures au plus après la réception. Un canal supprimé ou en pause, ou une adresse email pas encore confirmée par son destinataire, ne reçoit rien. L'historique de la page Notifications montre l'état de chaque canal (Envoyé, Nouvel essai prévu, Abandonné…) et peut être filtré par flux et par niveau. Le contenu des notifications est conservé 30 jours, puis supprimé automatiquement ; l'historique et la liste des flux sont exportables en CSV depuis la même page.

Pour un webhook, la charge utile habituelle (signée si la signature est activée) porte "type": "notification", un objet notification (id, flow, title, message, level, repeat_count, received_at) et "monitor": null.

Exemple : script de sauvegarde

#!/usr/bin/env bash
# Prévient sur vos canaux d'alerte selon le résultat de la sauvegarde.
NOTIFY_URL="https://pinguro.app/n/VOTRE_JETON"

if /usr/local/bin/backup.sh; then
  curl -fsS -X POST "$NOTIFY_URL" --data-urlencode "title=Sauvegarde terminée" -d level=success > /dev/null
else
  code=$?
  curl -fsS -X POST "$NOTIFY_URL" \
    --data-urlencode "title=Sauvegarde en échec" \
    --data-urlencode "message=Code de sortie : $code" \
    -d level=error > /dev/null
fi

Exemple : cron, seulement en cas d'échec

# Tous les jours à 3 h : sauvegarde, et notification seulement en cas d'échec
0 3 * * * /usr/local/bin/backup.sh || curl -fsS -X POST "https://pinguro.app/n/VOTRE_JETON" --data-urlencode "title=Sauvegarde en échec" -d level=error > /dev/null

Le || n'envoie la notification qu'en cas d'échec du script.

Exemple : hook Claude Code

Pour être prévenu quand Claude Code a fini de répondre, ajoutez un hook Stop dans ~/.claude/settings.json (ou .claude/settings.json d'un projet ; à fusionner avec un bloc "hooks" existant) :

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -fsS -X POST 'https://pinguro.app/n/VOTRE_JETON' --data-urlencode 'title=Claude a terminé' -d level=success > /dev/null || true"
          }
        ]
      }
    ]
  }
}

Le || true évite qu'un échec réseau gêne Claude Code. L'URL est un secret : dans le fichier d'un projet partagé, ne la commitez pas.

Status page publique

Chaque workspace peut avoir une page de statut publique, disponible sur tous les plans, à l'adresse https://pinguro.app/status/<slug>. Elle affiche tous les monitors du workspace (y compris ceux en pause, affichés « En pause » en gris : ils ne sont plus vérifiés et ne comptent pas dans le verdict global).

Important — page accessible à tous : toute personne ayant le lien peut consulter la page. Aucune authentification n'est requise. Le nom de chaque monitor y est affiché (l'adresse surveillée, elle, n'est pas publiée) : évitez d'y mettre des informations confidentielles (références internes sensibles, noms de clients confidentiels). Si certains services ne doivent pas apparaître, surveillez-les dans un autre workspace (plusieurs workspaces sont possibles à partir du plan Agency, pas encore commercialisé).

Contenu de la page

• Verdict global — « Tous les systèmes opérationnels », « Incident en cours » ou « Contenu modifié détecté ».
• État de chaque monitor, avec sa disponibilité sur les 30 derniers jours. Les monitors en pause y apparaissent « En pause », sans état vert ni rouge ; leur historique reste visible. Si tous les monitors sont en pause, le verdict devient « Surveillance en pause ».
• Barre de disponibilité sur 90 jours pour l'ensemble des monitors de la page, un jour par case, détail au survol.
• Incidents récents (les 20 derniers), en cours ou résolus, avec les mises à jour publiées (voir Timeline d'incident).
• Maintenances en cours, ou prévues dans les 7 prochains jours. Les vérifications faites pendant une maintenance ne comptent pas dans la disponibilité.
• Heure de la dernière vérification. La page ne se rafraîchit pas toute seule : rechargez-la pour voir les dernières informations.

Configuration

• Création — dans Page de statut, choisissez un identifiant (slug) puis cliquez sur Créer la page.
• Slug — modifiable sur le même écran. Doit être unique sur Pinguro, en lettres minuscules, chiffres et tirets. Si l'identifiant souhaité est déjà pris par un autre compte, choisissez une variante (ex : ajoutez un suffixe -fr, -2, -prod). Après un changement, l'ancienne adresse redirige vers la nouvelle et reste réservée à votre workspace : aucun autre compte ne peut la reprendre, et vous pouvez y revenir. Si le workspace est supprimé, son identifiant actuel reste réservé 12 mois à votre compte (les anciens sont libérés) ; si le compte est supprimé, il reste réservé 12 mois à personne. Au plus 20 identifiants par workspace et 40 par compte, anciens compris.
• Publication — la page peut être dépubliée à tout moment : son adresse renvoie alors une erreur 404 (page introuvable), et sa configuration est conservée.

Domaine personnalisé (plans Agency et Enterprise)

La status page peut aussi être servie sur votre propre sous-domaine, par exemple status.monentreprise.fr. Voir Domaine personnalisé.

Personnalisation

Plans Solo et au-delà (pas encore commercialisés).

• Logo (plan Solo et au-delà) — adresse d'une image hébergée en https://.
• Couleur principale (plan Solo et au-delà) — remplace la couleur par défaut.
• Marque blanche (plan Agency et au-delà) — retire le nom et le logo de Pinguro des pages vues par vos visiteurs, voir ci-dessous.

Marque blanche (plan Agency)

L'option Marque blanche de la page Page de statut s'applique à la status page du workspace, aux pages publiques de ses monitors, à leurs widgets et à leurs badges SVG :

• plus de pied de page « Propulsé par Pinguro » ;
• l'icône de l'onglet (favicon) devient votre logo, ou une icône neutre si vous n'avez pas de logo ;
• le nom Pinguro disparaît du titre et de la description des pages, et aucun lien vers pinguro.app n'est affiché.

Deux éléments restent : l'adresse des pages (https://pinguro.app/…, sauf pour la status page servie sur un domaine personnalisé) et un lien discret « Signaler un contenu », que l'hébergeur de la page est tenu de proposer. Si l'abonnement repasse sur un plan sans marque blanche, la marque Pinguro réapparaît aussitôt sur ces pages.

Domaine personnalisé

Plans Agency et Enterprise (pas encore commercialisés).

La status page d'un workspace peut être servie sur votre propre domaine, par exemple https://status.monentreprise.fr, avec un certificat HTTPS obtenu automatiquement. Il faut un sous-domaine : un domaine racine (monentreprise.fr) ne peut pas être utilisé.

Mise en place pas à pas

1. 1
   Enregistrer le domaine

   Dans Page de statut, carte Agency, saisissez le sous-domaine (sans https://) puis cliquez sur Enregistrer le domaine. Le statut passe à « En attente » et les enregistrements DNS à créer s'affichent.

2. 2
   Créer le CNAME

   Chez l'hébergeur DNS du domaine (registrar ou fournisseur DNS), créez un enregistrement CNAME de status.monentreprise.fr vers domaines.pinguro.app. Il sert à acheminer les visites et à obtenir le certificat HTTPS.

3. 3
   Créer le TXT de vérification

   Au même endroit, créez un enregistrement TXT nommé _pinguro.status.monentreprise.fr, avec la valeur affichée dans le tableau de bord. C'est la preuve que le domaine vous appartient : sans lui, la page n'est jamais servie sur ce domaine.

4. 4
   Attendre la validation

   La validation du domaine et le certificat HTTPS sont automatiques, en général en quelques minutes (jusqu'à 24 h selon la propagation DNS). La vérification est relancée toutes les 5 minutes ; le bouton Vérifier la relance tout de suite. Le statut passe alors à « Actif ».

Une fois le domaine actif, l'adresse https://pinguro.app/status/<slug> redirige vers votre domaine : les liens déjà partagés continuent de fonctionner. Sur ce domaine, seule la status page est servie.

Bon à savoir

• Délai de 7 jours — un domaine qui n'est pas validé dans les 7 jours suivant son enregistrement est retiré automatiquement. Il suffit de le saisir à nouveau une fois les enregistrements DNS en place.
• Domaine déjà réservé par un autre compte — si un autre compte Pinguro a saisi votre domaine sans prouver qu'il lui appartient, le tableau de bord affiche un enregistrement TXT _pinguro.<domaine> propre à votre page. Créez-le chez votre hébergeur DNS puis cliquez de nouveau sur Enregistrer le domaine : le domaine vous est attribué, avec la propriété déjà prouvée. Un domaine dont la propriété a été prouvée par un autre compte ne peut pas être repris.
• 3 domaines par compte au plus, tous workspaces confondus (un par status page).
• Enregistrements TXT facultatifs — le tableau de bord peut en proposer d'autres : ils permettent de valider le domaine avant de modifier le CNAME, par exemple si ce sous-domaine sert déjà une autre page.
• Retrait — le bouton Retirer détache le domaine aussitôt. Le domaine est aussi retiré si l'abonnement passe sur un plan sans domaine personnalisé ; la status page reste alors accessible à l'adresse https://pinguro.app/status/<slug>.

Dépannage

• Le certificat HTTPS n'est pas émis — vérifiez qu'aucun enregistrement CAA du domaine n'exclut les autorités de certification utilisées par Cloudflare, qui émet le certificat (notamment Let's Encrypt et Google Trust Services). Un enregistrement CAA qui ne les autorise pas bloque l'émission du certificat : ajoutez-les, ou retirez la restriction, puis cliquez sur Vérifier.
• Domaine géré par Cloudflare — laissez l'enregistrement CNAME en « DNS only » (nuage gris), et non en mode proxy (nuage orange).
• Le statut reste « En attente » — vérifiez l'orthographe des deux enregistrements (le nom du TXT commence par _pinguro.) et laissez le temps à la propagation DNS. Le tableau de bord indique si l'enregistrement TXT a été trouvé.

Page publique par monitor + widget

Plans Solo et au-delà (pas encore commercialisés).

Sur les plans Solo et au-delà, chaque monitor peut avoir sa propre page publique, avec sa disponibilité sur 24 heures, 7 jours et 30 jours, des barres de disponibilité sur 90 jours et l'historique des incidents. Elle s'active sur la page détail du monitor, dans la carte Partage public (Activer la page publique). Elle affiche seulement le domaine de l'adresse surveillée (par exemple app.exemple.fr), jamais son chemin ni ses paramètres, et rien pour un heartbeat.

Widget SVG embarquable

Une fois la page publique activée, la carte Partage public fournit l'URL publique et les snippets à copier. Deux formats disponibles :

Badge SVG (image)

<a href="https://pinguro.app/m/<identifiant-public>"><img src="https://pinguro.app/widget/<identifiant-public>.svg" alt="Status"></a>

Iframe

<iframe src="https://pinguro.app/widget/<identifiant-public>" width="300" height="80" frameborder="0"></iframe>

À coller dans le footer d'un blog, une page « À propos », ou la sidebar d'un outil interne.

Surveillance du contenu

Plans Solo et au-delà (pas encore commercialisés).

Option dédiée à détecter les modifications non-intentionnelles du contenu d'une page : défacement, altération après compromission, régression de déploiement. C'est une détection différentielle, pas une analyse sémantique — il n'y a pas d'IA derrière.

Comment ça marche

• Au premier check réussi, Pinguro normalise le contenu de la page (après retrait des sélecteurs ignorés), en calcule un hash SHA-256 et en note la taille. Ce hash et cette taille forment la baseline.
• À chaque check suivant, le contenu est normalisé de la même façon. S'il diffère de la baseline, Pinguro compare les tailles : si la variation de taille atteint le seuil configuré (10 % par défaut), une alerte content_changed est envoyée et un incident « contenu modifié » est ouvert. Tant que le changement persiste, l'alerte est répétée au plus une fois toutes les 24 heures.
• La baseline n'est mise à jour que lorsque vous cliquez sur Réinitialiser dans la config du monitor : cela ferme aussi l'incident « contenu modifié ».

Sélecteurs à ignorer

Pour éviter le bruit sur les blocs qui changent tout le temps (prix dynamique, timestamp, flux d'actu), listez des sélecteurs CSS à ignorer dans la comparaison — un par ligne :

.news
#trending
.comments
.price-widget

Syntaxe supportée : .classe, #identifiant, nom-de-balise. L'extraction est approximative (non-parser HTML), suffisante pour la plupart des cas.

Cas d'usage

• Home page critique — alerte si le CMS a perdu un bloc ou si un deploy a rendu une page blanche.
• Pages légales — CGU, mentions, politique de confidentialité. Toute modification silencieuse doit être détectée.
• Endpoints statiques — fichiers robots.txt, humans.txt, manifestes JSON.

Limites actuelles

• Pas d'exécution JavaScript — on compare le HTML brut renvoyé par le serveur.
• Pas de diff visuel — l'alerte indique uniquement le pourcentage de variation de taille. Une modification qui ne change presque pas la taille de la page (un mot remplacé par un autre de même longueur) peut passer sous le seuil.
• Incompatible avec la méthode HEAD (qui ne renvoie pas de corps).
• Aucune IA : on ne comprend pas si un changement est « voulu » ou non, c'est à vous d'acter via le bouton de réinitialisation.

Rapports SLA mensuels

Plans Solo et au-delà (pas encore commercialisés).

Générez un rapport mensuel de disponibilité, imprimable en PDF via la fonction d'impression de votre navigateur. Deux portées : par monitor (chiffres du mois, incidents, maintenances) et workspace (vue consolidée de tous les monitors actifs du workspace).

Sur les plans Agency et Enterprise, un résumé du mois écoulé est également envoyé automatiquement par email le 1^er de chaque mois (3h UTC) : disponibilité globale de l'ensemble de vos monitors, nombre d'incidents d'indisponibilité, durée cumulée d'indisponibilité et monitors les moins disponibles, avec un lien vers la page Plan qui ouvre le rapport complet du mois. Cet envoi est activé par défaut et se désactive depuis votre page Compte.

Comment les générer

• Par monitor — ouvrez le monitor, bouton Rapport SLA. Choisissez le mois cible, cliquez sur Ouvrir le rapport, puis Imprimer / Enregistrer en PDF.
• Workspace — depuis Plan → Rapports SLA, bouton Rapport du mois, choix du mois puis Ouvrir le rapport. Regroupe tous les monitors actifs du workspace.

Contenu d'un rapport

• Période couverte, date d'édition, monitor ou workspace concerné.
• Disponibilité en % (deux décimales) et temps de réponse moyen (monitors HTTP).
• Nombre de vérifications effectuées et nombre d'échecs.
• Liste des incidents avec type, début, fin et durée, et les notes publiées sur chaque incident.
• Fenêtres de maintenance planifiée : les vérifications faites pendant une maintenance sont exclues du calcul.

Gating par plan

• Free — pas d'accès.
• Solo — mois en cours uniquement.
• Agency — 12 derniers mois (mois en cours inclus).
• Enterprise — illimité, depuis la création du monitor.

Mois anciens (plus de 90 jours)

Le détail de chaque vérification est conservé au moins 90 jours (1 an sur Agency, 2 ans sur Enterprise, voir Plans et limites). Pour les mois de plus de 90 jours, le rapport s'appuie sur le bilan de chaque mois, enregistré une fois le mois terminé : disponibilité, nombre de vérifications et d'échecs, temps de réponse moyen. Les incidents et les maintenances restent listés en détail. Le rapport l'indique par la mention « Données mensuelles consolidées ». Pour les mois antérieurs à l'été 2026, le temps de réponse moyen peut ne pas être disponible : il s'affiche alors « — ».

Export des données (CSV)

Tous les plans, y compris Free.

Vos données vous appartiennent : vous pouvez télécharger à tout moment l'historique de vos monitors au format CSV, pour l'archiver, l'analyser dans un tableur ou le reprendre dans un autre outil. Tout membre du workspace peut exporter, y compris avec le rôle Viewer ; un export ne contient que les données du workspace sélectionné.

Comment exporter

• Vérifications d'un monitor — ouvrez le monitor, bouton Exporter (CSV), choisissez la période (24 h, 7 jours, 31 jours ou des dates précises) puis Télécharger les vérifications.
• Incidents d'un monitor — même fenêtre, bouton Télécharger les incidents : tout l'historique du monitor.
• Incidents du workspace — depuis la liste des monitors, bouton Exporter les incidents (CSV) : tous les incidents de tous les monitors du workspace.

Contenu des fichiers

• Vérifications — date, statut (Disponible / Indisponible), temps de réponse en millisecondes, code HTTP, raison de l'échec en clair, et si la vérification a eu lieu pendant une maintenance.
• Incidents — monitor, type (panne ou contenu modifié), début, fin, durée (en secondes et lisible) et si l'incident est toujours en cours.
• Aucune donnée sensible : ni en-têtes HTTP personnalisés, ni jetons, ni configuration des canaux d'alerte.

Format et limites

• Fichier CSV encodé en UTF-8, séparateur point-virgule : il s'ouvre directement dans Excel, LibreOffice ou Google Sheets. Les dates sont écrites au format AAAA-MM-JJ HH:MM:SS, dans le fuseau horaire de votre navigateur (indiqué dans l'en-tête de colonne).
• Le détail des vérifications est conservé selon le plan du propriétaire du workspace : 90 jours sur Free et Solo, 1 an sur Agency, 2 ans sur Enterprise. Au-delà, il n'est plus exportable. Après un passage à un plan inférieur, l'historique reste exportable sur l'ancienne durée pendant les 30 jours qui précèdent sa suppression. Chaque fichier couvre au plus 31 jours ; pour une période plus longue, faites plusieurs exports.
• L'export se fait depuis le tableau de bord (session connectée) ; il n'est pas accessible avec une clé API.

API publique

Plans Solo et au-delà (pas encore commercialisés).

Pinguro expose une API REST versionnée pour intégrer le monitoring dans vos scripts, Zapier, n8n, pipelines CI/CD, ou tout outil qui parle HTTP. L'API est disponible sur les plans Solo (2 clés max), Agency et Enterprise (illimité).

Base URL

https://pinguro.app/api/v1

L'API couvre quatre familles de ressources : les monitors, les groupes, les canaux d'alerte et les fenêtres de maintenance. Elle suit les mêmes règles de validation que l'interface web. L'URL /api/v1/* est stable : aucun changement incompatible ne sera publié sans une nouvelle version /api/v2/* en parallèle.

Authentification

Créez une clé depuis Dashboard → Clés API. Chaque clé commence par pgr_ suivi de 32 caractères hexadécimaux. La clé n'est affichée qu'une seule fois à la création — stockez-la dans votre gestionnaire de secrets.

Seuls le propriétaire et les admins d'un workspace peuvent créer, voir et révoquer ses clés API. Une clé n'agit que sur le workspace dans lequel elle a été créée, avec les droits de son créateur dans ce workspace : si ce dernier quitte le workspace ou en est retiré, ses clés sont révoquées. Une clé ne donne accès qu'aux quatre familles de ressources ci-dessus : l'équipe, les workspaces, la double authentification et l'abonnement se gèrent uniquement depuis le tableau de bord.

Deux façons d'authentifier une requête :

# En-tête dédié
curl -H "X-API-Key: pgr_votreclé" https://pinguro.app/api/v1/monitors

# Ou Authorization: Bearer
curl -H "Authorization: Bearer pgr_votreclé" https://pinguro.app/api/v1/monitors

Endpoints disponibles

GET /api/v1/monitors

Liste tous les monitors du workspace de la clé.

POST /api/v1/monitors

Crée un monitor. Body : { name, url, interval_minutes, type? }. Voir exemple ci-dessous.

PUT /api/v1/monitors/:id

Met à jour un monitor. Tous les champs sont optionnels (partial update).

DELETE /api/v1/monitors/:id

Supprime un monitor. Répond 204 No Content en cas de succès.

GET /api/v1/monitors/:id/stats

Détails d'un monitor, statistiques et incidents récents. Paramètre range : 24h, 7d, 30d.

GET / POST /api/v1/monitor-groups, PATCH / DELETE /api/v1/monitor-groups/:id

Liste, création, modification et suppression de groupes.

GET / POST /api/v1/maintenance-windows, PUT / DELETE /api/v1/maintenance-windows/:id

Liste, création, modification et suppression de fenêtres de maintenance.

GET / POST /api/v1/alerts/channels, PUT / DELETE /api/v1/alerts/channels/:id

Liste, création, modification et suppression des canaux d'alerte.

Codes de réponse

• 200 / 201 / 204 — succès.
• 400 — validation échouée, ou option non incluse dans votre plan. Format généralement { field, error }.
• 401 — clé API manquante, invalide, ou révoquée.
• 403 — opération refusée : limite du plan atteinte (ex. nombre de monitors), rôle insuffisant, clé qui n'a plus accès à son workspace, ou route hors de l'API publique.
• 404 — ressource introuvable ou appartenant à un autre workspace.
• 429 — rate limit dépassé (voir ci-dessous).
• 500 — erreur serveur. Réessayez ; si ça persiste, écrire à [email protected].

Rate limits

Chaque clé API est limitée à 100 requêtes par minute. Au-delà, l'API renvoie 429 Too Many Requests. Les en-têtes RateLimit-* indiquent le quota restant et la fenêtre courante.

Exemple : créer un monitor via curl

curl -X POST https://pinguro.app/api/v1/monitors \
  -H "X-API-Key: pgr_votreclé" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "API Gateway",
    "url": "https://api.exemple.com/health",
    "interval_minutes": 5
  }'

Exemple : lister les monitors

curl https://pinguro.app/api/v1/monitors \
  -H "X-API-Key: pgr_votreclé"

Équipe et invitations

Plans Solo et au-delà (pas encore commercialisés) : sur le plan Free, le compte est limité à 1 membre.

Les membres et leurs rôles sont définis par workspace. Vous pouvez donc avoir un workspace perso où vous êtes seul, et un workspace partagé "Client A" avec des collègues qui n'auront accès qu'à ce workspace-là (pas à vos monitors perso). Chaque membre a un rôle qui détermine ce qu'il peut faire dans ce workspace.

Rôles disponibles

• Owner — accès total au workspace, y compris la suppression. Le créateur du workspace en est l'owner, et c'est son plan qui s'applique au workspace.
• Admin — gère les membres et leurs rôles (sauf l'owner et les autres admins), les clés API, le journal des actions, et peut renommer le workspace, en plus de tout ce que peut faire un editor.
• Editor — crée, édite et supprime les monitors, les groupes, les canaux d'alerte, les fenêtres de maintenance et la page de statut. Ne gère ni les membres ni les clés API.
• Viewer — lecture seule sur tout : monitors, stats, incidents, status pages. Les secrets restent masqués pour lui : il voit les canaux d'alerte sans leur URL de webhook, leur jeton de bot Telegram ni la valeur de leurs headers, et les monitors sans la valeur de leurs headers HTTP ni l'URL de ping des heartbeats. Idéal pour un client qui veut voir l'uptime de ses sites sans pouvoir les modifier.

Inviter un collaborateur

Important : vérifiez le workspace actif dans le sélecteur en haut de la sidebar avant d'inviter. L'invité aura accès à ce workspace uniquement.

1. 1
   Sélectionnez le bon workspace

   Vérifiez le bandeau "Workspace actif" en haut de page. Si besoin, changez de workspace via le sélecteur dans la sidebar.

2. 2
   Dashboard → Équipe → Inviter un membre

   Le titre de la fenêtre d'invitation rappelle dans quel workspace vous invitez. Renseignez l'email et choisissez le rôle.

3. 3
   Le destinataire reçoit un email

   L'invitation contient un lien personnel valable 7 jours, à ouvrir en étant connecté avec l'adresse email invitée. Au-delà, il faudra envoyer une nouvelle invitation.

4. 4
   Il rejoint le workspace

   En cliquant sur le lien, il crée son compte (ou se connecte s'il a déjà un compte Pinguro) et est ajouté au workspace avec le rôle prévu. S'il a déjà ses propres workspaces, le vôtre apparaît simplement dans son sélecteur — son workspace perso n'est pas affecté.

Limite de membres par plan

La limite dépend du plan du propriétaire et s'applique à tous ses workspaces confondus (propriétaire, membres et invitations en attente comptés ensemble) :

• Free — 1 membre (vous seul).
• Solo — 3 membres.
• Agency — 10 membres.
• Enterprise — illimité.

Limite d'envoi des invitations

Chaque invitation part par email. Pour éviter les envois abusifs, un compte peut envoyer au plus 20 invitations par 24 heures, et une même adresse peut recevoir au plus 3 invitations par 24 heures (y compris une invitation retirée puis renvoyée). Au-delà, l'invitation est refusée avec un message indiquant de réessayer plus tard.

Timeline d'incident éditable

Vous pouvez publier des messages publics sur un incident (« on enquête », « cause identifiée », « mise à jour du serveur »…) : ils apparaissent sous l'incident sur votre status page et sur la page publique du monitor. Pendant la panne, vos utilisateurs suivent l'avancée sans avoir à vous écrire ; après coup, vous pouvez expliquer ce qui s'est passé. Ces notes n'ont aucun effet sur le taux de disponibilité. Elles figurent aussi dans les rapports SLA.

1. 1
   Sur la page du monitor

   Tant qu'un incident est ouvert, la carte Timeline de l'incident apparaît sous les graphiques. Pour un incident terminé (30 derniers jours), utilisez Ajouter une note sous l'incident, dans Incidents récents.

2. 2
   Postez vos updates

   Tapez un message court (2000 caractères maximum). Il est horodaté automatiquement. Astuce : commencez-le par l'étape en cours, par exemple [En cours d'analyse] ou [Cause identifiée].

3. 3
   C'est visible sur les pages publiques

   Les messages apparaissent sur la status page (/status/<slug>) et sur la page publique du monitor (/m/<slug>) dès que le visiteur charge ou recharge la page. Quand le monitor répond de nouveau, un incident de panne passe automatiquement en « résolu » et la timeline se ferme : publiez votre dernier message avant, si besoin. Un incident « contenu modifié », lui, ne se ferme que lorsque vous cliquez sur Réinitialiser dans la configuration du monitor.

Authentification 2FA

Pinguro supporte le second facteur TOTP (Time-based One-Time Password) compatible avec Google Authenticator, Authy, 1Password, Bitwarden, etc. Disponible sur tous les plans, recommandé pour un compte qui gère du monitoring d'infra critique.

Activer la 2FA

1. 1
   Compte → Double authentification (2FA)

   Depuis la sidebar, ouvrez Compte, carte Double authentification (2FA), cliquez sur Activer la 2FA.

2. 2
   Scanner le QR code

   Ouvrez votre app TOTP (Google Authenticator, Authy...) et scannez le QR code affiché. Elle commence à générer un code à 6 chiffres qui change toutes les 30 secondes. Le QR code est généré directement par Pinguro : la clé secrète qu'il contient n'est transmise à aucun service tiers. Vous pouvez aussi saisir la clé affichée en texte.

3. 3
   Confirmer avec un code

   Entrez le code affiché par l'app pour confirmer que l'association fonctionne. Sans cette étape, la 2FA n'est pas activée.

4. 4
   Sauvegarder les codes de secours

   Pinguro affiche 8 codes de secours à usage unique — copiez-les (bouton Copier les codes) et rangez-les en lieu sûr. Ils permettent de se reconnecter en cas de perte du téléphone.

   Attention. Les codes ne sont affichés qu'une seule fois. Si vous les perdez et que vous perdez aussi votre app TOTP, contactez le support pour un reset manuel (délai et vérification d'identité).

Désactiver la 2FA

Depuis Compte, carte Double authentification (2FA), bouton Désactiver la 2FA. Vous devrez confirmer avec votre mot de passe et un code à 6 chiffres de votre app TOTP.

Plans et limites

Les limites s'appliquent par compte, tous workspaces confondus, sauf les envois de notifications par API, comptés par jour et par workspace (le nombre de flux reste compté par compte). Les monitors en pause ne comptent pas dans la limite de monitors. Au plus 50 monitors actifs d'un même compte peuvent viser le même domaine (voir la FAQ). Les plans payants ne sont pas encore commercialisés : seul le plan Free est disponible aujourd'hui. L'intervalle minimum ne s'applique pas aux heartbeats, réglables de 1 minute à 30 jours sur tous les plans. Les données détaillées des vérifications sont conservées 90 jours sur Free et Solo, 1 an sur Agency et 2 ans sur Enterprise, puis supprimées automatiquement. En cas de passage à un plan inférieur, l'historique au-delà de la nouvelle durée est conservé encore 30 jours avant d'être supprimé : si vous revenez au plan supérieur pendant ce délai, rien n'est perdu. Écrire à [email protected] pour un devis Enterprise.

FAQ