Schedule a BigQuery query to run itself.

Before you start

• A working BigQuery 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 row count check that emails you if something looks off starts with a plain query:

SELECT COUNT(*) AS rows_loaded, MAX(loaded_at) AS last_load
FROM `my-gcp-project.ingest.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. You'll get a message every morning whether or not your Mac is actually open with QueryFlow running.

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

Choosing a schedule that fits the data

A table that updates once a day doesn't need an hourly check, it just adds noise and BigQuery cost for no new information. Match the interval to how often the underlying data actually changes: daily for most reporting tables, hourly or more frequent only for something genuinely near-real-time. This isn't a QueryFlow-specific rule, it's just wasted query cost otherwise.

What happens on a missed schedule

If your Mac was asleep or off when a job was due, it simply runs at its next scheduled time rather than queuing up 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.

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 by default, it logs the failure and waits for its next scheduled time. If a job is 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 rather than the next time you happen to check the job history.

Editing a schedule after the fact

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

Disabling instead of deleting

If a job is only paused for now, a seasonal report you don't need for a few months, 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 from scratch.

A quick note on time zones in the trigger

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