posthog/ai-plugin

managing-reminders

Create and manage PostHog reminders — private, human-paced nudges that fire as in-app notifications on a schedule, optionally linked to a PostHog resource.

Voir la source
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

Managing reminders

This skill guides you through creating and managing PostHog reminders. A reminder is a private, human-paced nudge to yourself: it fires an in-app notification on a schedule, with no condition attached. It can optionally link to a PostHog resource.

When to use this skill

Use this skill when the user:

  • Says "remind me to…", "nudge me", "ping me", or "don't let me forget"
  • Wants a one-off reminder at a specific date/time
  • Wants a recurring reminder (every day, weekly, every Monday, weekdays, monthly, etc.)
  • Wants to be reminded to review a specific dashboard, insight, experiment, flag, survey, notebook, replay, or error
  • Wants to see, change, or cancel reminders they have set

Reminder vs alert vs subscription

These three look similar but solve different jobs. Pick the right one:

  • Reminder — a human-paced nudge to yourself with no condition. It just fires an

in-app notification on a schedule ("remind me to review the launch dashboard every Monday"). If the user says "remind me to…", it is a reminder.

  • Alert — watches an insight's metric on a schedule and notifies only when a

threshold or anomaly condition is met ("tell me if signups drop below 100").

  • Subscription — delivers an insight or dashboard export/snapshot on a schedule via

email, Slack, or webhook ("email me this dashboard every morning").

If there is a condition to evaluate, it is an alert. If there is an export to deliver, it is a subscription. If it is just a timed nudge to a person, it is a reminder.

Scheduling shapes

A reminder uses exactly one of scheduled_at, recurrence_interval, or cron_expression. Providing zero or more than one is rejected.

One-off

Set scheduled_at to a future ISO 8601 timestamp. The reminder fires once, then becomes completed.

User saysField
"remind me tomorrow at 3pm"scheduled_at: <tomorrow 15:00 in the user's tz>
"remind me on Jan 5 at 9am"scheduled_at: "2026-01-05T09:00:00" (+ timezone)

Preset recurring

Set recurrence_interval to one of daily, weekly, monthly, yearly.

User saysField
"every day"recurrence_interval: "daily"
"every week"recurrence_interval: "weekly"
"every month"recurrence_interval: "monthly"
"every year"recurrence_interval: "yearly"

Cron recurring

Set cron_expression to a 5-field cron string (min hour day-of-month month day-of-week) when the cadence is a specific weekday or time the presets can't express.

User saysField
"every Monday at 9am"cron_expression: "0 9 * * 1"
"weekdays at 8:30"cron_expression: "30 8 * * 1-5"
"1st of the month at noon"cron_expression: "0 12 1 * *"

A reminder may fire at most 4 times per day — a more frequent cron (e.g. hourly) is rejected.

Timezone

Always pass timezone as the user's IANA zone (e.g. "America/New_York") when you know it, so wall-clock times like "9am" resolve to the right moment. If omitted, it defaults to the project timezone. Cron and preset schedules resolve in this zone; scheduled_at is an absolute instant, so include its offset or rely on the same zone.

Attaching a resource

To link the reminder to a PostHog object, set resource_type and resource_id together. The fired notification deep-links to that object. The resource must already exist in the project.

resource_typeresource_id is the…
dashboardnumeric id
insightshort_id
experimentnumeric id
feature_flagnumeric id
surveyid
notebookshort_id
replaysession_id
error_trackingissue id

Resolve the id first if the user gives you a name or URL (e.g. fetch the insight to get its short_id). Omit both fields for a standalone reminder with no linked resource.

Privacy and lifecycle

  • Reminders are private to the creating user and scoped to the current project. Other

users never see them.

  • They fire as in-app notifications — not email, Slack, or webhook.
  • A one-off becomes completed after it fires.
  • A recurring reminder stays active until deleted, or until its optional end_date passes

(then it becomes completed).

  • A one-off whose delivery permanently fails becomes errored — surface this via reminders-list

when reporting on a user's reminders.

The MCP tools

  • reminder-create — create a reminder
  • reminders-list — list the user's reminders (schedule, status, next fire time)
  • reminder-get — get one reminder by id
  • reminder-update — update title, message, schedule, timezone, end date, or attached resource

(changing the schedule recomputes the next fire time)

  • reminder-delete — delete a reminder, which stops it firing

Worked example

User: "Remind me to review the launch dashboard every Monday at 9am."

  1. Resolve the dashboard id (e.g. dashboard 67).
  2. Pick the schedule shape: a specific weekday + time → cron.
  3. Pass the user's timezone if known.
  4. Call reminder-create:
json
{
  "title": "Review the launch dashboard",
  "resource_type": "dashboard",
  "resource_id": "67",
  "cron_expression": "0 9 * * 1",
  "timezone": "America/New_York"
}

Confirm back to the user when it will next fire (use next_fire_at from the response), and that it will keep firing weekly until they delete it.

du même dépôt

Autres Skills

Tous les Skills
posthog
Officiel

assessing-heatmaps

Assesses what a page's heatmap is telling you and recommends concrete changes. Pulls click / rageclick / scroll-depth data for a URL, names the hot elements by cross-referencing autocapture events on the same page, and can create a saved heatmap the user opens in PostHog, then summarizes the behavior and proposes improvements.\nTRIGGER when: user asks what a heatmap shows, why people aren't clicking something, where users rage-click, how far they scroll, what to change on a page based on heatmap/click data, or to 'analyze/assess/review the heatmap' for a URL.\nDO NOT TRIGGER when: the user only wants to create a saved heatmap screenshot with no analysis (use heatmaps-saved-create directly), or is asking about session replay in general (use investigating-replay).

installations
1
GitHub Stars
80
Mis à jour
4 sept.
posthog
Officiel

auditing-endpoints

Audit every endpoint in a PostHog project for staleness, failed materialisations, and unused materialised versions. Use when the user asks "what endpoints can I clean up?", "are any of my endpoints broken?", "which materialised versions are still being called?", or wants a one-shot cleanup pass over the Endpoints product. Produces a prioritised report grouped by issue type, with recommended actions but does not modify anything without explicit confirmation.

installations
1
GitHub Stars
80
Mis à jour
4 sept.
posthog
Officiel

auditing-experiments-flags

Audit PostHog experiments and feature flags for configuration issues, staleness, and best-practice violations. Read when the user asks to audit, health-check, or review experiments or feature flags, check flag hygiene, or verify experiment setup.

installations
1
GitHub Stars
80
Mis à jour
4 sept.
posthog
Officiel

authoring-data-quality-checks

Adds and runs data quality checks (dbt-test style assertions) on a project's warehouse tables and saved-query views: not-null, uniqueness, accepted values, referential integrity, row-count bounds, freshness, and custom HogQL. Use when asked to test a model, validate a view, check for nulls or duplicates, add data quality checks, find out why a number looks wrong, or judge whether a warehouse table is trustworthy before using it in an analysis. To describe what data means (metrics, certifications, joins), see setting-up-data-catalog instead. Trigger terms: data quality, data test, dbt test, not null check, uniqueness check, freshness check, referential integrity, row count check, validate model, is this table trustworthy.

installations
1
GitHub Stars
80
Mis à jour
4 sept.