Schedule a Databricks query to run itself.

Before you start

• A working Databricks connection and a query you want to run repeatedly.
• File and email output are included in Studio. S3, SFTP, a database, Google Sheets, Slack and Teams need Pipelines.

Steps

1. Write or open your query in the SQL Editor.
2. Click Schedule in the toolbar.
3. Pick a Trigger Type: Manual, Interval, Daily, Weekly or Custom Cron, and set the time.
4. Choose where results go: No Output, Save to File, Email, or on Pipelines SFTP, Amazon S3, Database, Google Sheets, Slack or Microsoft Teams.
5. Turn on Enable immediately and click Create Job.
6. To run with QueryFlow closed, open Settings → Scheduling and turn on Run Jobs When App Is Closed.

With that toggle on, the background helper runs Snowflake, Redshift (IAM keys), BigQuery and Databricks jobs that deliver to S3, SFTP, a local file or email. Jobs with other sources or other destinations still need QueryFlow open.

A worked example

A daily check on a pipeline's row count, emailed if the run looks off:

SELECT count(*) AS rows_loaded, max(loaded_at) AS last_load
FROM ops.silver.events_raw
WHERE date(loaded_at) = current_date();

Schedule it Daily at 7 AM, output to Email, enable it, and turn on the closed-app toggle. It runs whether or not your Mac has QueryFlow open.

Matching the schedule to how often data actually changes

A table that refreshes nightly doesn't need an hourly check, it just adds load on the warehouse for no new information. Set the interval to match how often the underlying pipeline actually updates the data, daily for most reporting tables, more frequent only for something genuinely near-real-time.

What happens on a missed schedule

If your Mac was asleep or off when a job was due, it runs at its next scheduled time rather than queuing missed runs. Check the run history if a report seems to have skipped a day, it will show whether the job ran and failed, or never fired at all.

Check it worked

Open the job's run history after its first scheduled run. A successful run shows a timestamp, duration and row count; a failed one shows the error, usually the same message a connection Test would show.

Troubleshooting

See the full Schedule a BigQuery or Databricks query tutorial for every trigger and output option.

A word on failed runs

A scheduled query that fails doesn't retry automatically, it logs the failure and waits for its next scheduled time. For anything important enough that a single missed run matters, pair it with a Watch This alert on a related value so you find out the same day instead of the next time you happen to check the history.

Editing a schedule after the fact

You don't need to delete and recreate a job to change its timing or destination. Open it from the job list, adjust the Trigger Type or output, and save; its run history stays intact, so you can still see how it behaved under the old schedule.

Disabling instead of deleting

If a job is only paused for now, disable it rather than deleting it. Its schedule, output settings and history stay intact, and turning it back on later is a single toggle instead of rebuilding the whole thing.

A quick note on time zones in the trigger

Daily and Weekly triggers use your Mac's local time zone, not UTC and not the warehouse's. If you travel or your Mac's time zone setting changes, double-check a schedule that matters still fires when you expect.

Testing a new schedule before trusting it

Set a new job's first run for a time you'll actually be awake to check, rather than trusting an overnight schedule sight unseen the very first time. Confirm the output looks right once, then let it run unattended going forward.