Send a query's results to SFTP on a schedule.

Why SFTP is still how this gets done

Plenty of partner integrations and legacy systems were built around a file landing in a specific directory on a specific server, and that expectation hasn't changed just because the data on your side now lives in a cloud warehouse. Rebuilding that partner's ingestion process isn't on the table; getting a file there reliably, on a schedule, is the actual job.

Before you start

An SFTP destination added under Destinations (host, port, credentials, and target path, entered once), a working query, and Pipelines. File and email are Studio-tier; SFTP is one of the destinations that comes with Pipelines.

Steps

1. Add an SFTP destination once, if you haven't: click the + next to Destinations, choose SFTP, fill in host, port, credentials, and the target path, and save.
2. Write or open your query in the SQL Editor.
3. Click Schedule in the toolbar.
4. Pick a Trigger Type and set the time.
5. Choose your saved SFTP destination under output.
6. Turn on Enable immediately and click Create Job.

A worked example

A Snowflake query that exports the prior day's reconciled transactions for a payment partner every morning:

SELECT TRANSACTION_ID, ACCOUNT_ID, AMOUNT_CENTS, SETTLED_AT
FROM ANALYTICS.PUBLIC.TRANSACTIONS
WHERE SETTLED_DATE = CURRENT_DATE() - 1;

Schedule it Daily at 5:00 AM against the SFTP destination, ahead of the partner's stated cutoff for same-day processing. Because the source is Snowflake and the destination is SFTP, this is also one of the combinations the background helper covers, so it keeps firing with the Mac closed once Run Jobs When App Is Closed is on in Settings → Scheduling.

Check it worked

Check the job's run history for a successful run, then confirm the file landed in the expected directory on the SFTP server, ideally by having the partner (or your own monitoring on that server) confirm receipt independently of QueryFlow's own success status.

Troubleshooting

Naming the output file so the partner's side doesn't choke

Most partner SFTP ingestion processes expect either a fixed filename that gets overwritten each run, or a dated filename they pick up and archive. Which one you want depends entirely on what's reading the file on their end; a system doing its own date-based discovery wants a new filename per run, while a system that always polls the same path wants overwrite behavior. Confirm this with the partner before assuming either pattern, since guessing wrong means files silently piling up or getting missed.

Reusing the destination for other jobs

Because the SFTP destination is saved separately from any one job, the same server and credentials work for as many scheduled queries as you want, or for a Data Sync job's output, without re-entering anything. Add it once under Destinations and it shows up as an option every time you build a new schedule.

What this doesn't do

This delivers a file on a schedule; it isn't a monitored, guaranteed-delivery integration with retries beyond what the job's own retry settings provide, and it doesn't confirm the partner's system actually processed the file successfully once it lands. For a partner integration where delivery failure has real financial consequences, pair this with independent monitoring on either end, not just QueryFlow's own run history.

Bucket-equivalent permissions worth double-checking

The most common setup mistake with a new SFTP destination isn't a QueryFlow problem, it's a target directory the credential doesn't actually have write access to, or a path that's slightly different from what the partner documented. If Test on the destination succeeds but the actual scheduled job fails to write, that mismatch between what was tested and what the job needs is usually where to look first.

SFTP versus S3 as the delivery mechanism

When a partner or destination system can accept either, S3 is generally the lower-maintenance choice, since it doesn't depend on a specific server staying reachable and doesn't need SSH key rotation the way a long-lived SFTP credential does. SFTP remains the right call when the receiving system specifically requires it, which is common with older EDI-style partner integrations and some banking and payments processors that haven't modernized their ingestion path.

Key rotation on a long-lived credential

An SSH key used for an SFTP destination that runs unattended for months, or years, is easy to forget about until a partner's security policy forces a rotation on their end and the job starts failing with no warning. Treat the destination's credential the same way you'd treat any other production secret: know when it was last rotated, and check the job's run history periodically rather than only when someone notices the file stopped arriving.

What a failed delivery actually means downstream

A partner expecting a daily file has their own process waiting on it, and a silent delivery failure on your end can cascade into a stalled reconciliation or a missed processing window on theirs, often discovered well after the fact. Pairing the job's own failure notification, an email or Slack alert on job failure under Pipelines, with a periodic manual check that files are actually landing is worth the small extra effort for anything a partner's business process depends on.

Testing a new SFTP destination before it matters

Before pointing a real scheduled job at a newly added SFTP destination, run the query manually once with that destination selected and confirm the file actually lands where expected, with the content a receiving system can parse. It's a five-minute check that catches a wrong path or a permissions gap before the first real scheduled run, rather than discovering the problem when a partner asks why yesterday's file never arrived.

Coordinating a schedule change with the partner

If the query's schedule ever needs to move, an earlier cutoff time, a different day of the week, it's worth notifying the partner ahead of the change rather than assuming a file arriving at a new time is harmless on their end. Some partner ingestion processes run on their own fixed schedule and simply won't pick up a file that lands after their own cutoff, even though the file itself is fine.

Deciding whether to compress large files before delivery

A partner's SFTP ingestion process may or may not accept a compressed archive instead of a plain file, and it's worth confirming which format they expect before assuming either. For a genuinely large daily export, gzip-compressing before delivery can meaningfully cut transfer time; for a modest file the added complexity of managing compression rarely pays for itself and a plain delivered file is simpler to debug when something goes wrong.

Sources

• QueryFlow on the Mac App Store — accessed September 26, 2026