Gérer les rappels

Cette skill vous guide dans la création et la gestion des rappels PostHog. Un rappel est une notification privée, au rythme humain, qui vous nudge : elle déclenche une notification in-app selon un calendrier, sans condition attachée. Elle peut optionnellement se lier à une ressource PostHog.

Quand utiliser cette skill

Utilisez cette skill quand l'utilisateur :

Dit « rappelle-moi de… », « nudge-moi », « fais-moi signe », ou « ne me laisse pas oublier »
Veut un rappel unique à une date/heure spécifique
Veut un rappel récurrent (chaque jour, hebdomadaire, chaque lundi, les jours de semaine, mensuellement, etc.)
Veut être rappelé de vérifier un dashboard, insight, experiment, flag, survey, notebook, replay, ou error spécifique
Veut consulter, modifier, ou annuler les rappels qu'il a créés

Rappel vs alerte vs subscription

Ces trois éléments se ressemblent mais résolvent des besoins différents. Choisissez le bon :

Rappel — une notification privée, au rythme humain, sans condition. Elle déclenche simplement une notification in-app selon un calendrier (« rappelle-moi de vérifier le dashboard de lancement chaque lundi »). Si l'utilisateur dit « rappelle-moi de… », c'est un rappel.
Alerte — surveille la métrique d'un insight selon un calendrier et notifie uniquement quand une condition de seuil ou d'anomalie est atteinte (« dis-moi si les inscriptions tombent en dessous de 100 »).
Subscription — livre un export/snapshot d'insight ou de dashboard selon un calendrier via email, Slack, ou webhook (« envoie-moi ce dashboard par email chaque matin »).

S'il y a une condition à évaluer, c'est une alerte. S'il y a un export à livrer, c'est une subscription. Si c'est juste une nudge programmée à une personne, c'est un rappel.

Formes de planification

Un rappel utilise exactement une des trois : scheduled_at, recurrence_interval, ou cron_expression. Fournir zéro ou plus d'une est rejeté.

Unique

Définissez scheduled_at sur un timestamp ISO 8601 futur. Le rappel se déclenche une fois, puis devient completed.

L'utilisateur dit	Champ
« rappelle-moi demain à 3pm »	`scheduled_at: <demain 15:00 dans le fuseau de l'utilisateur>`
« rappelle-moi le 5 jan à 9am »	`scheduled_at: "2026-01-05T09:00:00"` (+ `timezone`)

Récurrent préset

Définissez recurrence_interval sur l'une de ces valeurs : daily, weekly, monthly, yearly.

L'utilisateur dit	Champ
« chaque jour »	`recurrence_interval: "daily"`
« chaque semaine »	`recurrence_interval: "weekly"`
« chaque mois »	`recurrence_interval: "monthly"`
« chaque année »	`recurrence_interval: "yearly"`

Cron récurrent

Définissez cron_expression sur une chaîne cron à 5 champs (min heure jour-du-mois mois jour-de-la-semaine) quand la cadence est un jour de la semaine ou une heure spécifiques que les presets ne peuvent pas exprimer.

L'utilisateur dit	Champ
« chaque lundi à 9am »	`cron_expression: "0 9 * * 1"`
« les jours de semaine à 8:30 »	`cron_expression: "30 8 * * 1-5"`
« 1er du mois à midi »	`cron_expression: "0 12 1 * *"`

Un rappel peut se déclencher au maximum 4 fois par jour — un cron plus fréquent (par ex. horaire) est rejeté.

Fuseau horaire

Toujours passer timezone comme la zone IANA de l'utilisateur (par ex. "America/New_York") quand vous la connaissez, pour que les heures d'horloge comme « 9am » se résolvent au bon moment. Si omis, il utilise par défaut le fuseau du projet. Les calendriers cron et presets se résolvent dans cette zone ; scheduled_at est un instant absolu, donc incluez son décalage ou fiez-vous à la même zone.

Joindre une ressource

Pour lier le rappel à un objet PostHog, définissez resource_type et resource_id ensemble. La notification déclenchée crée un lien profond vers cet objet. La ressource doit déjà exister dans le projet.

`resource_type`	`resource_id` est le…
`dashboard`	id numérique
`insight`	short_id
`experiment`	id numérique
`feature_flag`	id numérique
`survey`	id
`notebook`	short_id
`replay`	session_id
`error_tracking`	issue id

Résolvez d'abord l'id si l'utilisateur vous donne un nom ou une URL (par ex. récupérez l'insight pour obtenir son short_id). Omettez les deux champs pour un rappel autonome sans ressource liée.

Confidentialité et cycle de vie

Les rappels sont privés à l'utilisateur qui les crée et limités au projet actuel. Les autres utilisateurs ne les voient jamais.
Ils se déclenchent comme des notifications in-app — pas email, Slack, ou webhook.
Un unique devient completed après son déclenchement.
Un rappel récurrent reste active jusqu'à suppression, ou jusqu'à ce que son end_date optionnel passe (alors il devient completed).
Un unique dont la livraison échoue définitivement devient errored — signalez-le via reminders-list quand vous rapportez sur les rappels d'un utilisateur.

Les outils MCP

reminder-create — créer un rappel
reminders-list — lister les rappels de l'utilisateur (calendrier, statut, prochain déclenchement)
reminder-get — obtenir un rappel par id
reminder-update — mettre à jour titre, message, calendrier, fuseau horaire, date de fin, ou ressource attachée (changer le calendrier recalcule le prochain déclenchement)
reminder-delete — supprimer un rappel, qui arrête son déclenchement

Exemple travaillé

Utilisateur : « Rappelle-moi de vérifier le dashboard de lancement chaque lundi à 9am. »

Résolvez l'id du dashboard (par ex. dashboard 67).
Choisissez la forme de calendrier : un jour de la semaine spécifique + heure → cron.
Passez le fuseau horaire de l'utilisateur s'il est connu.
Appelez reminder-create :

{
  "title": "Review the launch dashboard",
  "resource_type": "dashboard",
  "resource_id": "67",
  "cron_expression": "0 9 * * 1",
  "timezone": "America/New_York"
}

Confirmez à l'utilisateur quand il se déclenchera ensuite (utilisez next_fire_at de la réponse), et qu'il continuera à se déclencher hebdomadairement jusqu'à ce qu'il le supprime.

managing-reminders