SFTP Automation: The Two Approaches and When to Use Each (2026)

Q: How do I automate SFTP file transfers?

There are two approaches. Automate on the server: configure the SFTP server to react to events (a file arriving) or to run on a schedule, and have it launch a process or send a notification. Or automate in your application: embed an SFTP client library in your own code and have the application connect, transfer, and handle retries itself. Server-side suits file exchange with partners who push or pull files. Client-side suits an application that already owns the workflow and needs files as part of it.

Q: What is the difference between scheduled and event-driven SFTP automation?

Scheduled automation runs on a clock: every 15 minutes, at 2am daily, or on a cron expression. It has to poll to find new files, so there is latency between a file arriving and being processed. Event-driven automation reacts to something happening on the server, such as a file upload completing, and fires immediately with no polling. Use scheduled for batch windows and outbound pushes. Use event-driven for reacting to partner uploads.

Q: How do I trigger a script when a file is uploaded to SFTP?

Use a process trigger on the file upload event. In CompleteFTP this is configured in the Process Execution tab: add a trigger, select the Upload file event, and specify the program to launch. Macros pass details of the uploaded file to your script. You can also set the trigger to fire on error as well as on success, which is how you catch failed uploads rather than discovering them later. Process triggers require the Professional or Enterprise MFT edition.

Q: Can OpenSSH on Windows automate SFTP transfers?

Partly. OpenSSH gives you the transfer itself, and you can schedule sftp or scp commands with Windows Task Scheduler or cron. What it does not give you is event-driven automation. There is no built-in way to run a script when a file finishes uploading, so you end up polling a directory on a timer and writing your own logic for partial files, retries, and errors. That works at small scale and becomes the thing you maintain instead of the thing you built.

Q: What is SFTP automation software?

It is either a file transfer server with automation built in (event triggers, scheduled events, notifications, scripting), or a separate orchestration tool that drives transfers between systems. For most shops moving files with partners, automation built into the SFTP server is the shorter path, because the server already knows when files arrive and who sent them.

Q: How do I automate SFTP transfers without polling?

Use server-side event triggers. The server already knows the moment an upload completes, so it can launch your process immediately instead of a scheduled job discovering the file later. This removes both the polling latency and the partial-file problem, where a timer-based script picks up a file that is still being written.

Q: What happens when an automated SFTP transfer fails?

That depends entirely on what you built, which is why it is worth deciding deliberately. Server-side triggers can be set to fire on error as well as on success, so a failed upload can raise a notification instead of passing silently. Client-side automation has to handle it in code: catch the timeout, reconnect, resume or restart the transfer. Long-running transfers of large files are where this matters most, because a connection drop at 90 percent is expensive if you restart from zero.

Automating SFTP transfers starts with one choice: the automation runs on the server, or it runs inside your application. The two suit different situations, and the wrong pick leaves you maintaining scripts the job did not need.

The choice matters because automation is not a niche requirement. Across the 1,621 organizations whose file transfer usage we have examined, automated exchange between systems, with no person involved at any point, is the most common thing they do with an SFTP server. It is more common than storing files or giving people somewhere to drop them, and it accounts for roughly half of them, whether the work runs on a schedule, on a trigger, or from inside an application.

The quick answer

Automate on the server when partners push files to you, or you push to them, and the file exchange is itself the workflow. The server already knows when a file arrives and who sent it, so it can be configured to react.

Automate in your application when the application already owns the workflow and the transfer is one step within it. You embed an SFTP client library, and your own code connects, transfers, retries, and continues.

Most production shops end up running both, because the two approaches serve different jobs.

What SFTP automation covers

In practice it covers some combination of:

Scheduled transfers. Push or pull at a fixed time or interval.
Event-driven actions. Something happens (a file lands), something else runs.
Multi-endpoint fan-out. The same file goes to several partner servers, or you collect from many.
Retry and resume. The connection drops at 90 percent and you don't start over.
Post-transfer actions. Move the file, notify someone, kick off a downstream job.

Only the first of these is really about scheduling. The rest concern what happens around the transfer, and they account for most of the configuration work.

Server-side or client-side

Server-side automation

The SFTP server does the work. It watches for events, runs on schedules, launches processes, and sends notifications.

Right when:

Partners upload to you and you need to react
The transfer is the workflow, not part of a bigger one
You want automation configured rather than coded
Several unrelated systems need to consume the same drop

Client-side automation

Your application is the SFTP client. It connects, transfers, and handles its own errors.

Right when:

Your app already has the business logic and files are one step
You're pulling from partner servers you don't control
You need transfer behaviour that lives in your code, in your deployment, under your tests
You're embedding transfer into something that isn't a file server at all

One financial services team put their side of it plainly:

"an application module serves as an SFTP client (using edtFTPj-pro for this) and connects to a server and uploads/downloads files as required continuously. If the server times out the connection, the application reconnects and start ftp download / uploads."

a US financial-data organization (EnterpriseDT support archive)

Their reconnect handling exists because the server times out idle connections, which is a routine consideration for any client that runs continuously rather than on demand.

If you have not yet settled on the server underneath any of this, our SFTP server buyer's guide works through the available categories and the point at which each one stops being suitable.

Server-side automation in practice

CompleteFTP handles this through events. An event is either something a logged-in user does, or something the server does on a schedule. Two things can hang off an event: an email notification, or a process trigger that launches a program.

Events and process triggers require the Professional or Enterprise MFT edition, as do email notifications and auditing, so confirm your edition before planning around them.

Event triggers

Process triggers are configured in the Process Execution tab. Add a trigger, name it, choose which events it applies to:

Upload file
Download file
Move file (rename or move)
Delete file
Create folder, Move folder, Delete folder
Log in, Log out

Macros pass the details of the file and user to whatever you launch.

Two checkboxes on the same screen control when a trigger fires: Trigger on success and Trigger on error. By default a trigger fires when the operation succeeds, and ticking the error box gives you a trigger when an upload fails instead. Without it, a broken partner feed stays invisible until someone downstream asks where the file is.

A trigger does not have to fire on every matching event. Filters narrow it by the folder or file path the operation touches, by the user performing it, and, on Enterprise MFT, by the site it runs on, so a trigger can be scoped to exactly the drop folder, account or site it is meant for.

Scheduled events

For time-based work, CompleteFTP schedules events four ways: a list of specific times, even time intervals, days of the week, or a cron expression. The schedule dialog is on the Process Triggers panel, via the Change link next to the Scheduled checkbox.

Cron expressions are supported alongside the simpler options. A cron expression is only a way of expressing when something should run, so time-based schedules and event-driven triggers run side by side on the same server.

Even intervals contain one trap, because the counter restarts when it passes the maximum of the unit. An event set for every 23 minutes starting at 13:11 fires at 13:23 and 13:46, then at 14:00 rather than 14:09. Choosing an interval that divides the unit maximum exactly, such as 15 minutes, avoids this.

Client-side automation in practice

When your application is the client, you embed a library and write the transfer into your own code. edtFTPj/PRO for Java and edtFTPnet/PRO for .NET are built for this, and both include SFTP support.

The trade-off is that complete control comes with complete responsibility for every failure mode, including timeouts, retries, resume, progress reporting and throughput. None of those are configured for you.

This is why the questions we receive about client-side automation tend to be about what happens once the upload works. A business software team, mid-build:

"We can upload and download correctly and now are testing other functionalities like progress notification, resume the upload, etc."

a Spanish business-software organization (EnterpriseDT support archive)

And once file sizes grow, throughput stops being theoretical. From a collections software team:

"I use edtFTPnet/PRO in a C# .net application for downloading and uploading files from various SFTP servers. For a long time it was only small files but recently I have started downloading 1gb and larger files and realized that the transfer speeds are very slow."

a US collections-software organization (EnterpriseDT support archive)

The plural in "various SFTP servers" matters: collecting from many endpoints is more common than the single-partner case, and it complicates throughput, retries and error handling together. Throughput itself is tunable rather than fixed, since both libraries expose buffer and window settings that raise transfer speed on large files, so a slow transfer of gigabyte-scale files is usually a matter of configuration rather than a hard ceiling.

Scale and fan-out

Automated processes don't connect like people do. An airline running continuous automated feeds described what that looks like from the server side:

"There is one ftp id on server which keeps on making ftp connection every 1 or 2 seconds through some automated process from remote client and this process runs continuously."

an Indian airline (EnterpriseDT support archive)

A single account reconnecting every second or two around the clock puts a very different load on the server from a person who logs in a handful of times a day. Once a fleet of automated clients is involved, the connection rate becomes a capacity question, and one to size before the automation goes live.

Fan-out raises the same question from a different direction. Sending one file to twelve partners means twelve connections and twelve authentication handshakes, any of which can fail because a single endpoint is unavailable. Decide early whether one failure should stop the whole batch or be retried on its own, because that decision is awkward to change once the workflow is in use.

When automation is the wrong answer

Automation is not always the right answer, and a few common situations call for something simpler.

Scheduled batch processing remains correct for batch work. If the finance team closes its books each evening, a nightly batch job is a reasonable design that event-driven triggers would only complicate.

Frequency matters as well. A transfer that runs once a week rarely justifies a trigger, because automation carries its own maintenance cost, and below a certain frequency a manual step is cheaper than a mechanism that can fail quietly for months before anyone notices.

OpenSSH combined with Task Scheduler is genuinely adequate at small scale, giving you the transfer and a timer. What it does not give you is event-driven reaction, so you end up polling a directory and writing your own handling for partial files, retries and errors. That approach holds up until you have more than two or three feeds, at which point the accumulated scripting has become a small automation framework that somebody has to maintain.

If you are weighing whether this needs a full managed file transfer platform or whether a capable SFTP server is enough, MFT vs SFTP covers that comparison.

These questions come up so often partly because of who is asking. Automated file transfer skews heavily towards regulated, integration-heavy shops: financial services first by a distance, then enterprise software, SaaS, cybersecurity, IT services, and healthcare. In those environments the automation usually has an auditor attached to it, which changes the calculation behind writing a quick script.

How to choose

Does the file arrive from someone else? Yes, and you need to react to it: server-side triggers.
Does your application already own the workflow? Yes: client library.
Is it time-based or arrival-based? Time: scheduled events. Arrival: event triggers.
Do you need to know when it fails? Then decide it now: set trigger-on-error or write the catch.

Many shops answer "both" to more than one of these, which is why running server-side and client-side automation together is so common.

Try it

The most direct way to evaluate this is to build a single trigger and watch it fire. Download the 30-day trial, set a process trigger on file upload, and drop a file into the folder to see what happens.

Download the 30-day trial - no credit card, no sales call
Compare editions - process triggers need Professional or above. Per-server perpetual licence, unlimited users
Process triggers documentation - the click-by-click reference

Frequently asked questions

How do I automate SFTP file transfers?

Two approaches. Automate on the server: configure it to react to events like a file upload, or to run on a schedule, launching a process or notification. Or automate in your application: embed an SFTP client library and have your code connect, transfer, and handle retries. Server-side suits partner file exchange. Client-side suits an application that already owns the workflow.

What is the difference between scheduled and event-driven SFTP automation?

Scheduled runs on a clock and has to poll to find new files, so there's latency between arrival and processing. Event-driven reacts the moment something happens on the server and fires immediately, no polling. Scheduled for batch windows and outbound pushes. Event-driven for reacting to partner uploads.

How do I trigger a script when a file is uploaded to SFTP?

Use a process trigger on the upload event. In CompleteFTP: Process Execution tab, add a trigger, select the Upload file event, specify the program. Macros pass the file details to your script. Set trigger-on-error too, so failed uploads raise something instead of passing silently. Requires Professional or Enterprise MFT.

Can OpenSSH on Windows automate SFTP transfers?

Partly. You get the transfer, and you can schedule it with Task Scheduler. You don't get event-driven automation, so you poll a directory on a timer and write your own logic for partial files, retries, and errors. Fine at small scale. Past a few feeds, the scripting around it becomes its own thing to maintain.

What is SFTP automation software?

Either a file transfer server with automation built in (event triggers, scheduled events, notifications, scripting), or a separate orchestration tool driving transfers between systems. For most shops moving files with partners, automation built into the server is the shorter path, because the server already knows when files arrive and who sent them.

How do I automate SFTP transfers without polling?

Server-side event triggers. The server knows the moment an upload completes, so it launches your process immediately. That removes the polling latency and the partial-file problem, where a timer-based script grabs a file that's still being written.

What happens when an automated SFTP transfer fails?

That depends on what you built, which is the point. Server-side triggers can fire on error as well as success, so a failure raises a notification. Client-side has to handle it in code: catch the timeout, reconnect, resume or restart. It matters most on large files, where a drop at 90 percent is expensive if you restart from zero.