Analysis triggers
An analysis trigger is a schedule attached to an existing analysis that queues a fresh run automatically when it fires. Instead of returning to the platform to press "Run" every week, you configure the cadence once and Diafunc re-runs the analysis on your behalf — reusing the same data table, targets, questions, segment key, and depth preset as the original run.
This is the fastest way to keep a report current: point a trigger at an analysis whose underlying data source refreshes on a schedule, and each run picks up the latest data and rebuilds the report with it.
This is the fastest way to keep a report current: point a trigger at an analysis whose underlying data source refreshes on a schedule, and each run picks up the latest data and rebuilds the report with it.
Not the same as function triggers
Diafunc has two unrelated features that both use the word "trigger". They are easy to confuse, so it is worth being explicit:
A function trigger runs a single function evaluation; an analysis trigger runs an end-to-end analysis (data preparation, symbolic-regression modelling, and report generation). If you were looking for the event-driven function triggers configured in the Lab (and the
Functions
| Feature | What it does | Where |
|---|---|---|
| Analysis trigger | Re-runs a whole analysis on a schedule, producing a fresh report each time. | This page. |
| Function trigger | Invokes an Intelligent Function on a time- or event-driven basis (for example when a table changes). | Documented under Functions. |
A function trigger runs a single function evaluation; an analysis trigger runs an end-to-end analysis (data preparation, symbolic-regression modelling, and report generation). If you were looking for the event-driven function triggers configured in the Lab (and the
trigger command group in the CLI), see the Functions documentation instead. Schedule kinds
Every trigger has a kind that decides how often it fires and a schedule spec that gives the exact time or cadence.
A Quartz cron expression has six fields —
| Kind | Fires | Schedule spec | Example |
|---|---|---|---|
One-off (ONCE) | A single run at one moment in time, then deactivates itself. | An ISO-8601 instant (UTC). | 2026-07-01T06:00:00Z |
Recurring (CRON) | A run on every occurrence of the cron expression, indefinitely, until you pause or delete it. | A Quartz cron expression. | 0 0 6 * * ? |
A Quartz cron expression has six fields —
second minute hour day-of-month month day-of-week. For example 0 0 6 * * ? means "at 06:00:00 every day", and 0 30 7 ? * MON means "at 07:30 every Monday". Cron times are interpreted in UTC. Creating a schedule in the platform
Open the Analysis panel for a project from the Lab left menu and find the Schedules section below the run history. Press Add schedule to open the editor and pick a cadence: every day (a time of day), every week (a weekday and a time), every month (a day of the month and a time), once, at a set time (a single moment), or advanced, which takes a raw Quartz cron expression for cadences the presets do not cover.
The recurring presets build the cron expression for you, so you only need Quartz syntax for the advanced option. Every time field is in UTC, which is the zone the platform evaluates schedules in. As you fill the editor in, it shows the exact moment the schedule would first run, resolved by the platform rather than guessed in the browser; an expression that cannot be parsed, or one whose last occurrence has already passed, says so there, and Create stays disabled until the schedule has a real next run.
Once saved, the schedule appears in the table described in plain words, such as "Every Monday at 07:15 UTC", with its raw spec underneath, its next run (also in UTC, like every other time on this surface), and its status. Each row can be paused (temporarily stop firing without losing the schedule), resumed, or removed. A paused trigger keeps its configuration but never fires until you resume it.
The recurring presets build the cron expression for you, so you only need Quartz syntax for the advanced option. Every time field is in UTC, which is the zone the platform evaluates schedules in. As you fill the editor in, it shows the exact moment the schedule would first run, resolved by the platform rather than guessed in the browser; an expression that cannot be parsed, or one whose last occurrence has already passed, says so there, and Create stays disabled until the schedule has a real next run.
Once saved, the schedule appears in the table described in plain words, such as "Every Monday at 07:15 UTC", with its raw spec underneath, its next run (also in UTC, like every other time on this surface), and its status. Each row can be paused (temporarily stop firing without losing the schedule), resumed, or removed. A paused trigger keeps its configuration but never fires until you resume it.
Creating a trigger from an agent (MCP)
The same schedules can be managed programmatically through the Diafunc MCP tools, which is convenient when an assistant or automation manages the analysis. Four tools cover the lifecycle:
Schedule a single run at a fixed time:
Schedule a recurring run — here, every day at 06:00 UTC:
Pause a trigger without deleting it by updating its
create_analysis_trigger, list_analysis_triggers, update_analysis_trigger, and delete_analysis_trigger. Schedule a single run at a fixed time:
create_analysis_trigger — one-off
Schedule a recurring run — here, every day at 06:00 UTC:
create_analysis_trigger — recurring
Pause a trigger without deleting it by updating its
active flag (pass a new scheduleSpec instead to reschedule it — the spec must match the trigger's existing kind): update_analysis_trigger — pause
What happens when a trigger fires
When a trigger's next fire time arrives, Diafunc queues a brand-new analysis run that reuses the parent analysis's recipe — the same raw data table, analysis function, targets, questions, and depth preset. The run joins the normal queue and, when it starts, produces a fresh report exactly as if you had pressed "Run" by hand. It appears in the same run history as your manual runs.
Because a trigger re-runs against whatever data currently lives in the analysis's data table, pairing a trigger with a data source that refreshes on its own schedule keeps the report continuously up to date.
After firing, a one-off trigger deactivates itself — it has done its single job. A recurring trigger computes its next fire time from the cron expression and waits for the next occurrence. Each fired run consumes credits at the analysis's depth preset, just like a manual run, so keep the cadence and depth in mind for recurring schedules.
Because a trigger re-runs against whatever data currently lives in the analysis's data table, pairing a trigger with a data source that refreshes on its own schedule keeps the report continuously up to date.
After firing, a one-off trigger deactivates itself — it has done its single job. A recurring trigger computes its next fire time from the cron expression and waits for the next occurrence. Each fired run consumes credits at the analysis's depth preset, just like a manual run, so keep the cadence and depth in mind for recurring schedules.