Règles

Disponible avec les plans Pro et Pro Plus.

Les règles décident quand une alerte part, une fois qu'un canal sait où l'envoyer. Elles vivent dans Projet → Alertes → Règles, sous l'encadré « En l'état » qui résume ce qu'elles produisent ensemble. Toutes s'appliquent à tous les canaux à la fois : email, Discord, Slack et webhook sortant. Aucune ne touche à la surveillance elle-même : les vérifications tournent, l'historique et les incidents s'écrivent, c'est l'envoi qui obéit.

Ce que PostShip fait

Confirmation avant alerte

Par défaut, une alerte part dès le premier échec. Vous pouvez exiger 2 ou 3 échecs d'affilée avant d'alerter, pour absorber un faux positif ponctuel du réseau, au prix d'une détection plus lente (2 passages à 5 minutes, c'est 10 minutes de plus).

La règle compte la série : fail et error l'allongent, pass la remet à zéro. L'alerte part quand la série franchit le nombre choisi, pas à chaque passage suivant : une page en panne toute la nuit ne vous écrit qu'une fois. Elle réécrit seulement si la panne change de nature (un 503 devenu 404, un fichier manquant devenu délai dépassé). Le rétablissement n'est annoncé que si l'alerte d'échec était partie : avec une confirmation à 3 et une panne de 2 passages, vous ne recevez ni l'un ni l'autre.

C'est aussi ce nombre qui décide de l'ouverture d'un incident : l'incident naît à la N-ième confirmation, au moment précis où PostShip accepte de vous écrire.

Heures calmes

Une plage horaire quotidienne, de « De » à « À » (heures entières, 0 à 23), dans le fuseau de votre choix. Une plage qui traverse minuit (22 h → 7 h) est comprise. Laisser l'un des deux champs sur « Désactivé » désactive la plage. Pendant ces heures :

• une panne du paiement — une page de paiement du pack ou un parcours en échec — vous réveille quand même ;
• tout le reste (autres échecs, rétablissements, modifications de contenu, dérives DNS) est retenu ; les vérifications continuent et les incidents s'ouvrent normalement ;
• au premier passage après la fin de la plage, un rapport de la nuit part sur vos salons et par email : les incidents ouverts pendant la plage, ceux qui se sont refermés seuls, ceux qui durent encore. Rien ne part si la nuit a été calme.

Affiner : 4 règles de plus

Sous les heures calmes, la carte « Affiner » porte 4 règles, chacune sur son interrupteur. Un geste enregistre ; aucun bouton. Toutes retardent ou trient, aucune ne bloque : une page de paiement passe toujours devant.

• Délai minimum avant alerte : n'alerter que si la panne dure depuis au moins 5 min à 12 h, en plus des échecs consécutifs. PostShip note l'instant du premier échec de la série ; l'alerte part au passage où les deux conditions sont réunies pour la première fois, jamais aux suivants. Une page qui trébuche 2 passages et repart n'est pas une panne.
• Heures ouvrées : des jours de la semaine et un créneau (« 09:00 » → « 18:00 », dans le fuseau des heures calmes ; un créneau qui passe minuit appartient au jour où il commence). En dehors, la règle des heures calmes s'applique : une page de paiement cassée alerte tout de suite, le reste est retenu — l'incident s'ouvre, le résumé quotidien le dit.
• Gravité par type de page : ce que reçoivent les pages de paiement et ce que reçoivent les autres — « Tous les canaux, tout de suite », « L'email seulement » (les salons et le webhook n'en entendent pas parler), ou « Le résumé quotidien » (rien d'immédiat). Un rétablissement, une modification de contenu ou une dérive DNS suivent la règle des autres pages.
• Regroupement : attendre 2 à 30 min pour rassembler les échecs qui tombent à quelques passages d'écart en une seule alerte. Les éléments attendent sur le projet ; le passage qui voit la fenêtre échue — ou le tick, quelques minutes plus tard — les envoie ensemble. Une page tombée puis revenue dans la fenêtre ne donne rien. Les aperçus de déploiement ne sont jamais regroupés.

Couper les alertes maintenant

3 boutons, « 1 h », « 4 h », « 24 h », sur la page Incidents (barre « Couper ») comme dans Alertes → Maintenances, et « Reprendre les alertes » pour annuler. C'est le geste d'astreinte : la sirène a sonné, on sait, on ne veut pas l'entendre 6 fois. Pour une coupure prévue à l'avance, préférez une fenêtre de maintenance, qui a une fin, une raison et se voit sur la page de statut.

Silence d'une URL

Dans le menu d'une URL (page URLs), « Couper les alertes 4 h » retire cette URL seule des alertes pendant 4 heures ; le reste du projet continue d'alerter. « Reprendre les alertes » annule. La section « URLs en sourdine » d'Alertes → Maintenances les liste avec leur échéance et un bouton « Reprendre ».

Régler

Projet → Alertes → Règles, groupe « Quand vous êtes prévenu » :

• Confirmation avant alerte : « 1 échec », « 2 échecs d'affilée », « 3 échecs d'affilée ». Enregistrer.
• Heures calmes : De, À, Fuseau. Enregistrer. Le fuseau par défaut est celui de votre compte.
• Affiner : 4 interrupteurs — délai minimum (menu de 5 min à 12 h), heures ouvrées (jours, De, À), gravité (pages de paiement, autres pages), regroupement (menu de 2 à 30 min). Chaque geste enregistre.

Ce qui bloque et ce qui retarde est résumé en tête de page : « Il faut 2 échecs consécutifs sur la même URL avant qu'une alerte parte. » ou « Entre 22 h et 7 h (Europe/Paris), seul le paiement réveille ; le reste est rapporté au réveil. »

Ce qui déclenche une alerte

Dans l'ordre, pour chaque passage :

1. La série d'échecs franchit le nombre de confirmation, et la panne dure depuis le délai minimum s'il y en a un : une alerte d'échec est due.
2. Les alertes du projet sont coupées, une maintenance est en cours : rien ne part, sur aucun canal.
3. L'heure est calme, ou hors heures ouvrées : seules les pages de paiement en échec restent.
4. L'URL est silencieuse : elle est retirée du message ; si c'était la seule, rien ne part.
5. Un regroupement est réglé : les éléments attendent la fin de la fenêtre.
6. La gravité par type de page décide des canaux pour chaque élément.
7. La même alerte (même URL, même empreinte) est partie il y a moins de 10 minutes : rien ne part.
8. Sinon, envoi sur chaque canal branché, voir Email, Discord, Slack.

Limites et plans

Voir les plans.

Dépannage

Pourquoi l'alerte est partie malgré une confirmation à 3 ?

Regardez la page de l'URL : la série a bien atteint 3 échecs consécutifs, peut-être sur 3 passages à 5 minutes que vous n'avez pas vus. Un error (délai dépassé, DNS introuvable) compte comme un échec.

Pourquoi je n'ai pas eu d'alerte pour une panne de la nuit ?

Parce que la panne ne touchait pas au paiement : elle a été retenue, et le rapport de fin de plage l'a listée (« Toujours en cours » ou « Rétabli »). L'incident est dans Projet → Incidents, et sur la page de statut s'il a été publié.

Pourquoi « Couper les alertes 4 h » sur une URL n'a pas fait taire le projet ?

C'est le silence d'une seule URL. Pour tout le projet, utilisez « Couper 1 h / 4 h / 24 h » sur la page Incidents ou dans Alertes → Maintenances.

Maintenance

Disponible avec les plans Pro et Pro Plus.

Une fenêtre ponctuelle ou une règle hebdomadaire pendant laquelle rien n'alerte, annoncée sur la page de statut.

Une fenêtre de maintenance est une coupure des alertes décidée à l'avance, avec une fin qu'on ne peut pas oublier de rétablir et une raison qui explique le trou dans l'historique une semaine plus tard. C'est la différence avec « Couper 4 h », qu'on presse après que la sirène a sonné. Pendant la fenêtre, les vérifications continuent : l'historique reste vrai sur ce que le site a fait, seuls les envois sont retenus.

Ce que PostShip fait

2 formes, qui s'additionnent :

• La fenêtre ponctuelle : un début, une fin, une raison facultative (80 caractères). Elle se termine d'elle-même ; il n'y a rien à réactiver.
• Les maintenances récurrentes : un ou plusieurs créneaux, chacun avec ses jours de la semaine, une heure de début, une heure de fin et une raison facultative, dans un fuseau commun. « Tous les dimanches de 03:00 à 04:30 (Europe/Paris) », réglé une fois. Si la fin précède le début, la fenêtre court jusqu'au lendemain : « samedi de 23:00 à 01:00 » couvre bien le dimanche à 0 h 30.

Pendant l'une ou l'autre :

• Aucune alerte ne part, sur aucun canal, pour aucune URL du projet. C'est le même tout-ou-rien que les heures calmes de Règles.
• Le badge public affiche « maintenance » plutôt que « up ».
• La page de statut passe en état dégradé avec la raison, et la carte de déploiement le mentionne.
• La cause probable d'un incident ouvert pendant la fenêtre retient « Maintenance annoncée » avec le score le plus fort : c'est la seule cause qu'on peut presque affirmer, quelqu'un l'a annoncée.

Et avant :

• La page de statut annonce une fenêtre ponctuelle à venir dans les 24 heures, avec l'heure et la raison. Au-delà de 24 h, l'information ne sert pas à celui qui vient de trouver le site lent.
• Le calendrier public liste tout ce qui est prévu sur 30 jours (12 occurrences au plus), ponctuelle comprise, et le sert aussi en .ics à l'adresse /s/votre-slug/maintenance.ics pour Google Agenda, Outlook ou Apple. Voir Calendrier de maintenance.

Régler

Projet → Alertes → Maintenances réunit tout ce qui fait taire les alertes : « Couper maintenant », les URLs en sourdine, le calendrier des fenêtres et la règle hebdomadaire. Couper maintenant et les URLs en sourdine sont sur tous les plans ; le reste de la page demande Pro.

Fenêtre ponctuelle

Carte « Planifier une fenêtre » : le jour sur le calendrier (2 mois), l'heure de début, la durée (7 jours au plus, sans chevauchement), une raison facultative, par exemple « migration Postgres ». La phrase en bas relit la fenêtre avant que vous la posiez. Les fenêtres à venir et en cours sont listées sous « Planifiées », avec « Annuler » ; les passées sous « Passées », avec le nombre de vérifications en échec pendant — tues sur le moment, gardées dans l'historique. La fenêtre courante ou la prochaine est celle que la page de statut annonce et que le calendrier .ics porte.

Maintenances récurrentes

Carte « Maintenances récurrentes » : un créneau par phrase, « Chaque L M M de 03:00 à 04:00 », avec une raison facultative. « Ajouter un créneau » en pose un autre (jeudi et vendredi de 18:00 à 19:00, par exemple), dix au plus ; « Retirer » l'enlève. Un seul fuseau pour tous les créneaux, un seul « Enregistrer ». Une fin avant le début veut dire « jusqu'au lendemain ». La ligne du bas dit la prochaine maintenance, et l'en-tête de la carte affiche « En cours · … » pendant un créneau.

Ce qui déclenche une alerte

Rien pendant la fenêtre. Une panne qui commence pendant la maintenance et dure après n'est pas rejouée à la fin : PostShip n'alerte qu'à la transition, et l'incident reste visible dans Projet → Incidents. Une panne qui commence après la fin alerte normalement.

L'encadré « En l'état » de Règles vous le dit quand c'est le cas : « Une fenêtre de maintenance court jusqu'au 14/09 04:30 : rien ne sortira d'ici là. » ou « Maintenance récurrente en cours — tous les dimanches de 03:00 à 04:00 (Europe/Paris) : rien ne sort d'ici la fin. » Une fenêtre programmée pour la semaine prochaine n'y apparaît pas : elle n'explique pas un silence d'aujourd'hui.

Limites et plans

La page de statut et son calendrier existent sur tous les plans ; ils n'annoncent une maintenance que si une fenêtre a pu être réglée. Voir les plans.

Dépannage

Pourquoi une alerte est partie pendant ma maintenance ?

Vérifiez le fuseau des maintenances récurrentes : une fenêtre « 03:00–04:00 » en UTC n'est pas 3 h à Paris. La fenêtre ponctuelle, elle, est saisie dans votre heure locale. L'encadré « En l'état » dit si une fenêtre est en cours au moment où vous le lisez.

Pourquoi la page de statut n'annonce pas ma fenêtre de la semaine prochaine ?

L'annonce en tête de page ne porte que sur les 24 heures à venir. La fenêtre est bien dans le calendrier des 30 prochains jours et dans le flux .ics.

Pourquoi le badge dit « maintenance » alors que rien n'est en cours ?

Une règle récurrente est en cours à cette heure-là. Regardez la carte « Maintenances récurrentes » : son en-tête affiche « En cours · … » quand c'est le cas.

Acquittement

« Je m'en occupe » : dire à l'équipe que quelqu'un est déjà sur l'incident, et rendre la main.

Quand le salon s'allume, la première question d'une équipe de 2 personnes ou plus n'est pas « qu'est-ce qui casse » mais « est-ce que quelqu'un est déjà dessus ». L'acquittement y répond : un bouton « Je m'en occupe », un nom, une heure, et un message sur les salons pour que les autres lâchent. Ce n'est pas une astreinte, et ça n'arrête aucune alerte : PostShip n'en renvoie pas pour la même panne de toute façon.

Ce que PostShip fait

• Le bouton « Je m'en occupe » n'apparaît que sur un incident ouvert et non pris : on n'acquitte pas une panne refermée, ni 2 fois.
• Le premier qui clique gagne : 2 personnes qui acquittent à la même seconde ne s'écrasent pas ; la seconde lit « Cet incident est déjà pris en charge, ou refermé. »
• L'incident affiche ensuite « Pris en charge par marie il y a 12 min » : la partie de l'adresse email avant l'arobase, ce qu'on dit à l'oral. L'adresse entière n'apporte rien de plus sur une ligne de salle d'incident.
• Les salons du projet (Discord, Slack) reçoivent un message texte : « marie prend en charge l'incident », suivi du résumé de l'incident. Le retour d'écran le confirme : « Pris en charge — annoncé sur discord, slack. » ou simplement « Pris en charge. » si aucun salon n'est branché.
• L'escalade, si elle est réglée, ne se déclenche jamais pour un incident acquitté : c'est exactement ce qu'elle attend.
• La cause probable et le post-mortem notent la prise en charge sur la chronologie : « Pris en charge par marie à 14:07 (UTC), 4 min après le début. » Ou, sinon : « Personne n'a pris en charge cet incident. »

Rendre la main

« Rendre la main » retire la prise en charge : l'incident redevient « à prendre » et le bouton « Je m'en occupe » réapparaît pour tout le monde. Aucun message n'est envoyé sur les salons. Si l'escalade est réglée et que le délai est dépassé au moment où la main est rendue, l'incident sera escaladé au prochain passage, sauf s'il l'a déjà été (une fois par incident).

Où

Projet → Incidents, sur chaque salle d'incident, au-dessus de la phrase publique. L'ordre est voulu : on ne rédige un message pour les clients qu'une fois qu'on sait qui regarde. Le bouton n'existe pas dans les salons de discussion ni via l'API : acquitter suppose d'avoir ouvert l'incident.

Qui peut acquitter

Le propriétaire du projet et les membres éditeurs. Pour un membre en lecture seule, l'écriture est refusée : il lit « Cet incident est déjà pris en charge, ou refermé. » et rien n'est enregistré.

Ce qui déclenche un message

Un salon injoignable ne rend pas l'acquittement faux : l'écriture est faite d'abord, l'annonce ensuite, au mieux.

Limites et plans

L'acquittement existe sur tous les plans. Il prend son sens avec des collaborateurs (Pro Plus) et des salons branchés (Pro). Voir les plans.

Dépannage

Pourquoi le bouton « Je m'en occupe » n'apparaît pas ?

L'incident est déjà pris (le nom est affiché) ou déjà résolu. Un incident refermé ne s'acquitte plus ; son post-mortem dira qui l'a pris, ou que personne ne l'a pris.

Pourquoi le message n'est pas arrivé sur Slack ?

Le retour d'écran liste les salons qui ont accepté le message. Si Slack n'y est pas, le webhook a répondu une erreur : reconnectez-le depuis Intégrations. La prise en charge, elle, est bien enregistrée.

Pourquoi le nom affiché n'est pas le mien ?

C'est la partie avant l'arobase de l'adresse email du compte qui a cliqué. Si 2 membres partagent le même préfixe (marie@a.example.com, marie@b.example.com), le nom sera le même : le reste se dit dans le salon.

Escalade

Disponible avec les plans Pro et Pro Plus.

Un incident que personne n'a pris en charge au bout de N minutes est renvoyé à toute l'équipe, une fois.

La première alerte part au propriétaire et sur les salons. Si personne ne clique « Je m'en occupe » parce que le propriétaire est en réunion, en vacances, ou que l'alerte s'est perdue dans un salon bavard, l'incident dort. L'escalade est le second coup de sonnette, à tous les membres cette fois, par email : le canal qui finit toujours par être lu. Pas d'astreinte, pas de rotation : c'est le plus petit mécanisme qui évite qu'une panne reste orpheline.

Ce que PostShip fait

Toutes les 2 minutes, pour chaque projet où un délai est réglé, PostShip cherche les incidents qui réunissent 4 conditions :

• ouverts (pas de rétablissement),
• sans prise en charge,
• jamais escaladés,
• commencés depuis plus de N minutes.

Pour chacun, il marque l'escalade puis envoie le même message sur 2 voies à la fois :

• Par email, à tous les destinataires : le propriétaire du projet et les membres qui ont accepté leur invitation, dédoublonnés. Sujet : Incident sans prise en charge depuis 30 min — Mon site. Corps : le résumé de l'incident, « Personne n'a cliqué « je m'en occupe ». Quelqu'un ? », et un bouton « Prendre en charge » vers la page Incidents.
• Sur les salons branchés (Discord, Slack) : le même texte.

Une fois par incident. L'escalade ne se répète pas, ne remonte pas d'un cran, et n'existe pas pour un incident déjà pris ou déjà refermé. 2 passages qui se chevauchent ne peuvent pas escalader 2 fois : le marquage est posé avant l'envoi.

Régler

Projet → Alertes → Règles, groupe « Si personne ne répond » : un menu.

Enregistrer. Le délai court depuis le début de l'incident, pas depuis l'alerte : avec une confirmation à 3 échecs, l'incident commence à la troisième confirmation.

Ce qui déclenche l'escalade, et ce qui ne la déclenche pas

• L'escalade ignore les règles d'envoi des alertes : heures calmes, « Couper », maintenance ne la retiennent pas. Un incident ouvert pendant une maintenance et non pris sera escaladé au bout du délai. Si vous ne voulez pas d'escalade cette nuit-là, réglez « Pas d'escalade » le temps de l'opération.
• Un incident pris en charge avant le délai n'est jamais escaladé, même si la main est rendue après.
• Un incident résolu avant le délai n'est jamais escaladé.
• L'escalade apparaît sur la chronologie de la cause probable : « Escaladé à toute l'équipe à 14:37 (UTC), 30 min après le début. »

Limites et plans

Voir les plans et Équipe.

Dépannage

Pourquoi l'escalade n'est pas partie ?

Regardez l'incident : il a été pris en charge ou résolu avant le délai, ou bien il l'avait déjà été (une seule fois par incident). Vérifiez aussi que le délai est réglé sur ce projet, pas sur un autre.

Pourquoi j'ai reçu l'escalade alors que j'avais coupé les alertes ?

C'est voulu : « Couper » retient les alertes de vérification, pas le rappel qu'une panne n'a personne dessus. Cliquez « Je m'en occupe » sur l'incident, ou passez l'escalade sur « Pas d'escalade » pendant l'opération.

Pourquoi un membre n'a pas reçu l'email ?

Seuls les membres dont l'invitation est acceptée sont destinataires. Une invitation en attente ne reçoit rien.