Scheduled jobs

A scheduled job runs one SQL statement on a cron schedule. Use it for recurring reports, for appending new rows into your lake, and for delivering results into your own database.

Scheduled Jobs → New. Give it a name, the SQL, a cron expression and a time zone.

Field	Notes
Name	Unique within your company
SQL	One statement. Reads and writes are both allowed
Cron	Standard 5-field cron, e.g. `0 6 * * *` for 06:00 every day
Time zone	Any IANA name, e.g. `Europe/Istanbul`. The cron is evaluated in this zone, so `0 6 * * *` stays 06:00 local across daylight-saving changes

Each occurrence fires once. A job can be paused and resumed without losing its definition.

Whose permissions a job runs with

A job runs with its owner's catalog access: the same catalogs, with the same read or write grants, the owner has in Studio. If the owner loses write access to a catalog, a job that writes to it starts failing.

Recipes

Append yesterday's rows into the lake:

INSERT INTO lake.default.orders
SELECT * FROM sales_pg.public.orders
WHERE  created_at >= current_date - 1 AND created_at < current_date;

Deliver a daily summary into your own PostgreSQL:

INSERT INTO reporting_pg.public.daily_revenue
SELECT current_date - 1 AS day, region, sum(total) AS revenue
FROM   lake.default.orders
WHERE  created_at >= current_date - 1 AND created_at < current_date
GROUP  BY region;

current_date - 1 style filters are pushed down into the source, so each run reads only the new slice. now() and month arithmetic are not; see what is pushed in Getting data in.

Results and history

Every run appears in Query History with its status, duration and resources. A run's result set is scratch and expires after a day like any other query's, so a job that should keep its output writes it to a table, as the recipes do.

There is no delivery by email, webhook or file yet. For several dependent steps, tests or freshness alerts in Slack, use a pipeline.

Getting data in Pipelines