Keep automated transfers running through temporary failures

Automated file transfers depend on networks and remote systems that are not always available. A brief outage, a maintenance window, or a temporary permission problem should not require an operator to restart every affected workflow.

SFTPPlus MFT can retry different kinds of failure independently, preserve source files until delivery succeeds, and notify operators when a problem continues.

Retry failed connections ​

A location defines how SFTPPlus connects to a remote server. It contains the address, credentials, and retry policy used when a connection cannot be established.

Connection failures can include:

• A network problem that makes the remote server unreachable.
• A remote service that is stopped for maintenance.
• An authentication request that the remote server rejects.

For each location, an administrator can configure how many times SFTPPlus retries the connection and how long it waits between attempts. This lets a transfer continue automatically when the remote service becomes available again.

Retry individual file operations ​

SFTPPlus handles file operation errors separately from connection errors. A connection might succeed while an upload, download, rename, or delete operation is temporarily denied.

The transfer configuration controls retries for these file-level failures. Separate policies for the location and transfer make it possible to respond differently to an unavailable server and a problem affecting one file operation.

The fault-tolerant transfer documentation describes the available retry settings.

Preserve the source until delivery succeeds ​

When a workflow is configured to remove or archive source files, SFTPPlus performs that action only after a successful transfer. If a transfer remains incomplete after its retries, the source file stays in place so a later run can try again.

Destination conflict rules add another layer of protection. A transfer can fail, skip the incoming file, replace the destination deliberately, or keep both files under different names. See file overwrite protection for the available policies.

Record failures and notify operators ​

Every failed attempt produces an audit event. Event handlers can filter those events and send an email, call an HTTP webhook, write a dedicated log, or publish a notification through another supported service.

Alerts can be limited to the final failure after all retries are exhausted. This avoids notifying operators about a short interruption that SFTPPlus has already recovered from.

Detect when expected files never arrive ​

Some failures happen before SFTPPlus sees a file. An upstream process might stop producing its weekly report, leaving no transfer error to record.

A transfer can define a minimum number of files expected during an interval. SFTPPlus generates an event when the observed count is lower, allowing the same notification system to report the missing activity.

For example, if an accounting process normally creates payment files every Friday, an alert can be sent when no files are transferred during that period. This detects a silent upstream failure as well as a failed delivery.

Together, retries, source preservation, audit events, and activity monitoring keep routine interruptions from becoming manual recovery work.