Before you start
A working connection and a query written against yesterday's data, since "every morning" almost always means "as of yesterday" rather than a query re-run against today's still-incomplete numbers.
Steps
- Write or open your query in the SQL Editor.
- Click Schedule in the toolbar.
- Pick Daily as the Trigger Type and set the time.
- Choose an output: Save to File, Email, or a Pipelines destination.
- Turn on Enable immediately and click Create Job.
A worked example
A BigQuery query for yesterday's new signups, scheduled to run at 6:30 AM:
SELECT signup_source, COUNT(*) AS signups FROM `my-gcp-project.app`.users WHERE DATE(created_at) = CURRENT_DATE() - 1 GROUP BY signup_source ORDER BY signups DESC;
Daily trigger, 6:30 AM, output to email or a file, whichever fits how you actually want to read it. Because the source is BigQuery, this also qualifies for the background helper's app-closed list if the output is file or email, so it fires whether or not you've opened your laptop yet.
If your Mac wasn't awake
Sleep and wake behave differently from being fully powered off. If the Mac is asleep at 6:30 and wakes at 8, the queued job runs within seconds of waking, and the run history shows both the scheduled time and the actual run time so you can see the gap. If the Mac was completely off, the job waits until you next launch QueryFlow.
Check it worked
Open the job's run history the next morning and confirm a run logged near the scheduled time, then check that the output (file, inbox, or destination) actually has the day's data.
Troubleshooting
| If you see | Fix |
|---|---|
| Job ran hours late | The Mac was asleep past the trigger time; it caught up on wake. Use Power Schedule in System Settings if the exact time matters. |
| Job didn't run at all | Check the source and output qualify for the background helper, or that QueryFlow was open at the trigger time. |
| Numbers look incomplete | Confirm the query filters to a fully closed day, not a partial "today." |
Picking a time that actually works
6 AM is a common default, but it's worth checking against when the source data is actually final. A warehouse fed by an overnight ETL job that finishes at 5:45 leaves you cutting it close; a job scheduled for 6:30 gives that pipeline breathing room. If your morning query occasionally comes back with numbers that look one day behind, the trigger time is usually the first thing to check, not the query itself.
Stacking several morning jobs
Most people end up with more than one morning report over time: sales, signups, a data-quality check, maybe a cost report. Each is its own scheduled job with its own trigger time and its own run history, so there's no need to bundle unrelated queries into one to save on setup. Staggering trigger times by a few minutes (6:15, 6:20, 6:25) also avoids piling every job onto the exact same second, which is a minor courtesy to whatever warehouse is on the receiving end.
"Every morning" versus "every weekday"
Daily really does mean every single day, weekends included. For a report nobody reads on Saturday, Weekly with several days selected, or a Custom Cron expression like 0 630 * * 1-5, keeps the job from firing (and consuming warehouse credits) on days it won't be looked at. It's a small thing, but over a year it adds up, both in noise and in whatever the underlying query costs to run against a warehouse billed by usage.
Making the report worth opening
A morning query that just dumps every row of a table isn't a report, it's an export. The queries that actually get read tend to answer a specific question: what changed, what's trending the wrong way, what needs attention today. Spending a few extra minutes on the WHERE clause and the GROUP BY, rather than automating a "select everything" query, is usually what separates a morning job people actually check from one they eventually mute.
Full steps for building the job: the scheduling tutorial.