Documentation Pinguro

Introduction

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

Les choix clés d'Pinguro : un dashboard dense sans être surchargé, une configuration lisible (pas d'assistants à 7 étapes), des alertes qui arrivent vraiment (anti-faux-positif, attente de deux échecs consécutifs), une status page publique par défaut, et une API REST pour automatiser.

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 ou 15 min selon le plan).

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.

4. 4
   Enregistrez

   Le premier check part dans les secondes qui suivent. Les données apparaissent dans la ligne du monitor : statut, dernière latence, disponibilité 24h.

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 non-vide, la résolution doit retourner exactement ces IPs (tri indifférent). Maximum 20.

Comment ça marche

À chaque check, Pinguro interroge les résolveurs publics, compare le résultat à votre configuration :

• Pour A et AAAA avec IPs attendues : alerte si la résolution échoue ou si les IPs retournées diffèrent de 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 le timeout, 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 ton 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).
• Délai de grâce — combien de temps on tolère un retard avant d'alerter. 0 à 1440 minutes (défaut 5 min).

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.

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/TON_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/TON_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)

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. Élargissez à 200–399 si votre site redirige (3xx), ou 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).

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 strings.

Vérification SSL

Active la surveillance du certificat HTTPS. Vous recevez une alerte 7 jours avant l'expiration. Repose sur l'extension de la date notAfter — pas de révocation OCSP.

Groupes

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

• 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.

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, dans le fuseau du compte.
• Scope — tous les 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 planifiée.
• Les rapports SLA excluent les minutes de la fenêtre du calcul de disponibilité.

Accessible à tous les plans

Pas de gating par plan. Chaque compte peut planifier autant de fenêtres que nécessaire.

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é.

Email

Canal par défaut, créé automatiquement à l'inscription vers l'adresse du compte. Vous pouvez en ajouter d'autres pour alerter plusieurs personnes.

Slack

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. Pinguro POST le payload suivant sur votre URL :

{
  "event": "down",
  "monitor": {
    "id": 42,
    "name": "Site vitrine Acme",
    "url": "https://acme.com"
  },
  "status": "down",
  "error": "Timeout 10s",
  "at": "2026-04-18T14:21:07Z"
}

Les évènements possibles sont down, up, ssl_expiring, content_changed. Vous pouvez ajouter des headers personnalisés (ex. Authorization) dans la configuration du canal.

Webhooks signés (HMAC-SHA256)

Activez l'option Signer les requêtes sortantes pour qu'Pinguro signe chaque POST avec un secret partagé. Votre serveur peut alors vérifier que la requête provient bien d'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

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}.{raw_body}".encode()
    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']);
}

Status page publique

Chaque compte dispose d'une page de statut publique à l'adresse https://pinguro.app/status/<slug>, affichant en temps réel vos monitors partagés.

Configuration

• Slug — modifiable dans Page de statut → Paramètres. Doit être unique, 3–40 caractères, URL-safe.
• Visibilité par monitor — chaque monitor a un toggle Afficher sur la page publique.
• Groupes — les monitors sont regroupés sur la page publique selon leur groupe Pinguro, avec le nom et la couleur.

Domaine custom (plan Agency)

Pointez un CNAME de status.votredomaine.com vers status.pinguro.app, puis validez le domaine dans l'app. Le certificat TLS est émis automatiquement.

White-label et branding (plan Agency)

• Logo personnalisé (PNG/SVG transparent, max 200 KB).
• Couleur d'accent — remplace le violet Pinguro.
• Masquer la mention « Powered by Pinguro ».
• Message d'en-tête et lien de contact.

Page publique par monitor + widget

Chaque monitor a sa propre page publique (si le toggle Afficher sur la page publique est activé) avec graphique 30 jours, historique des incidents, et latence moyenne.

Widget SVG embarquable

Dans Monitor → Partage public, copiez le snippet. Deux formats disponibles :

SVG inline (statique, recharge au render)

<img
  src="https://pinguro.app/status/<slug>/<monitor-id>.svg"
  alt="Statut du site"
  height="28"
/>

Iframe (mise à jour live)

<iframe
  src="https://pinguro.app/status/<slug>/<monitor-id>/embed"
  width="260" height="40"
  frameborder="0" scrolling="no">
</iframe>

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

Surveillance du contenu

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 calcule un hash SHA-256 du contenu textuel de la page après extraction grossière des nœuds pertinents. Ce hash devient la baseline.
• À chaque check suivant, un nouveau hash est calculé. Si le taux de variation entre l'ancien et le nouveau contenu dépasse le seuil configuré (en %), une alerte content_changed est envoyée.
• La baseline est mise à jour dans deux cas : (1) vous cliquez manuellement sur Réinitialiser dans la config du monitor, (2) plusieurs checks consécutifs détectent le même nouveau contenu (stabilisation après un déploiement).

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 — le rapport d'alerte indique uniquement le taux de variation.
• 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

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

Les rapports SLA sont également envoyés automatiquement par email aux comptes Agency et Enterprise le 1^er de chaque mois (3h UTC) — opt-in/opt-out depuis votre page Compte.

Comment les générer

• Par monitor — ouvrez le monitor, bouton Rapport SLA. Choisissez le mois cible, puis Imprimer / enregistrer en PDF.
• Compte — depuis Plan → Rapports SLA, bouton Rapport du mois. Regroupe tous les monitors actifs.

Contenu d'un rapport

• Période couverte, date d'édition, nom du compte.
• Disponibilité globale en % (deux décimales).
• Durée cumulée d'indisponibilité (downtime minutes).
• Liste des incidents avec horodatage, durée, cause (code HTTP, timeout, mot-clé manquant...).
• Minutes de maintenance planifiée, exclues du calcul.

Gating par plan

• Free — pas d'accès.
• Solo — mois en cours uniquement.
• Agency — historique jusqu'à 12 mois en arrière.
• Enterprise — historique illimité.

API publique

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 le plan Solo (2 clés max) et Agency (illimité).

Base URL

https://pinguro.app/api/v1

Les endpoints sont identiques à ceux de /api/* utilisés par l'interface web. L'URL /api/v1/* est stable : nous ne ferons pas de breaking change sans publier /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.

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 vos monitors.

GET /api/v1/monitors/:id

Via /stats : détails, dispo 24h/7j/30j, incidents, checks récents. Utilisez GET /api/v1/monitors/:id/stats?range=24h.

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

Statistiques et incidents récents. Paramètre range : 24h, 7d, 30d.

GET /api/v1/monitor-groups / POST /api/v1/monitor-groups

Liste et création de groupes.

GET /api/v1/maintenance-windows / POST /api/v1/maintenance-windows

Liste et création de fenêtres de maintenance.

GET /api/v1/alerts/channels

Liste des canaux d'alerte configurés.

Codes de réponse

• 200 / 201 / 204 — succès.
• 400 — validation échouée. Format { field, error }.
• 401 — clé API manquante, invalide, ou révoquée.
• 403 — opération refusée par votre plan (ex. limite de monitors atteinte).
• 404 — ressource introuvable ou appartenant à un autre utilisateur.
• 429 — rate limit dépassé (voir ci-dessous).
• 500 — erreur serveur. Réessayez ; si ça persiste, contactez-nous.

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

Pinguro organise vos accès autour d'une organisation : un compte = une organisation avec un propriétaire, et autant de membres que votre plan le permet. Chaque membre a un rôle qui détermine ce qu'il peut faire.

Rôles disponibles

• Owner — accès total, y compris la facturation, le transfert de propriété et la suppression du compte. Il y a toujours exactement un owner par organisation.
• Admin — gère les membres et leurs rôles, les clés API, les canaux d'alerte, en plus de tout ce que peut faire un editor. Ne touche pas à la facturation.
• Editor — crée, édite et supprime les monitors, les groupes, les fenêtres de maintenance et les pages de statut. Ne gère ni les alertes ni les membres.
• Viewer — lecture seule sur tout : monitors, stats, incidents, status pages. Idéal pour un client qui veut voir l'uptime de ses propres sites sans pouvoir les modifier.

Inviter un collaborateur

1. 1
   Dashboard → Équipe

   Depuis la sidebar, ouvrez Équipe. Cliquez sur Inviter un membre, renseignez l'email et choisissez le rôle.

2. 2
   Le destinataire reçoit un email

   L'invitation contient un lien signé valable 7 jours. Au-delà, il faudra renvoyer une nouvelle invitation.

3. 3
   Il rejoint l'organisation

   En cliquant le lien, le destinataire crée son compte (ou se connecte s'il a déjà un compte Pinguro) et est ajouté à l'organisation avec le rôle prévu.

Limite de membres par plan

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

Timeline d'incident éditable

Pendant qu'un incident est ouvert, vous pouvez publier des mises à jour publiques (« on enquête », « cause identifiée », « rollback en cours », « résolu ») qui apparaissent en temps réel sur votre status page et la page publique du monitor — comme un postmortem live qui rassure vos utilisateurs.

1. 1
   Quand un incident est ouvert

   Allez sur la page détail du monitor concerné. Tant que l'incident n'est pas résolu, la card Timeline de l'incident apparaît au-dessus du graphique.

2. 2
   Postez vos updates

   Choisissez un statut (investigating, identified, monitoring, resolved) et tapez un message court. L'update est horodaté et stocké en base.

3. 3
   C'est visible immédiatement

   Les updates apparaissent en temps réel sur la status page publique (/status/<slug>) et la page publique par monitor (/m/<slug>). Vos utilisateurs voient l'avancée sans avoir à vous écrire.

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 → Sécurité

   Depuis la sidebar, ouvrez Compte, section Authentification à deux facteurs, cliquez sur Activer.

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.

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 10 codes de secours à usage unique — téléchargez-les ou imprimez-les 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 → Sécurité → Désactiver. Vous devrez fournir un code TOTP valide (ou un code de secours) pour confirmer.

Plans et limites

Les limites s'appliquent par compte. Un changement de plan prend effet immédiatement après le paiement Stripe. Contactez-nous pour un devis Enterprise.

FAQ