Data quality triggers and schedules

PostHog selects a trigger based on how each table, view, or metric receives new data. Connected tables and views run checks after data changes. Metrics and PostHog tables run checks on recurring schedules. You can run enabled checks manually anywhere.

Run checks manually

Use the check's actions menu and select Run now to run one check. Use Run all checks on a table, view, or metric to run all of its enabled checks.

The project-wide Data quality page also has Run all checks. It runs every enabled check that you can access across the project.

Manual runs use the permissions of the person who starts them. They don't change the automatic schedule or its last run.

Run checks after a source sync

Checks on a connected warehouse table run after that table completes a source sync. A check on one table doesn't wait for or run with other tables from the same source.

PostHog tables don't have source syncs. Checks on events, persons, and groups use schedules instead.

Run checks after view refreshes

A materialized view runs its checks as part of its refresh. This tests the version produced by that materialization run.

A saved view that PostHog refreshes as part of data modeling runs its checks when the view refreshes. PostHog refreshes related views in dependency order, then starts the applicable checks for each view that ran.

A saved view without an automatic refresh has no automatic check trigger. Run its checks manually.

Disabling a check prevents it from running after source syncs, view refreshes, schedules, and manual Run all checks actions.

Schedule metric and PostHog-table checks

Metrics and PostHog tables don't have a source-sync or materialization event. Each metric or table gets one schedule for all of its enabled checks.

Saving the first check on a metric or PostHog table creates an enabled daily schedule and starts an initial run. Open it on the project-wide Data quality page, expand it, and use:

• Run automatically to pause or resume the schedule.
• The interval selector to choose Every hour, Every 6 hours, Every 12 hours, Daily, or Weekly.

The metric's Tests tab shows the same schedule controls. Pausing a schedule sets its next run time to empty, but manual runs remain available.

Agents can also change these schedules through MCP. See the data quality MCP and SQL reference for automation details.

Understand schedule timing

PostHog spreads metrics and tables across each interval instead of starting every schedule at the same moment. The schedule shows its next execution time.

Scheduled runs follow these rules:

• If the previous scheduled workflow is still running, PostHog skips the overlapping occurrence.
• If the scheduling service misses an occurrence, it catches up only when it can start within 15 minutes of the original time.
• A failed run doesn't pause later scheduled runs.
• Pausing a schedule doesn't cancel a check that is already executing.
• Manual runs keep their normal behavior and don't take the place of scheduled occurrences.

PostHog rechecks the schedule, feature access, enabled checks, and execution permissions when a scheduled run starts. Every check on events, persons, or groups, plus every Custom SQL and Relationships check, uses the permissions of the person who last changed the check. If that person is unavailable, PostHog uses the creator. If neither person exists, the check records an error and runs no SQL. Other check types on connected tables and views use service authorization.

Keep schedule settings when checks change

Disabling or deleting every check on a metric or PostHog table keeps its interval and pause setting. Scheduled occurrences then execute no check queries. If you add or re-enable a check later, the existing schedule settings still apply.

If schedule settings can't be loaded or an update has an uncertain result, reload them before making another change. The original update might have succeeded.