What to Monitor First After Deploying SFTP

July 2026

An SFTP source is healthy when the deployed SSH user can authenticate and read the files matched by the configured remote path from the runner environment.

Short Answer

Monitor the first real file listing and read from the exact SFTP host, port, username, and remote_path you deployed. The source docs define the connector around those fields plus either a password or private_key_path, so the first healthy signal is a successful SSH login from the runner followed by one readable file under the configured path or glob.

That is stronger than seeing the SSH port open. A deployment can reach port 22 and still fail the actual workload because the key path is wrong, the user has no read access to /data/*.json, or the remote path is aimed at a directory the user cannot list. If one file is read from the intended path, you have validated the actual source boundary.

Why Teams Struggle with This

SFTP deploys often look close to done because SSH connectivity is visible, but the first useful post-deploy checks are authentication behavior and remote-path access, not port reachability alone.

• The runner must reach the configured host and port from its own network, not just from a jump box or terminal session.
• The SSH user needs read access to the exact remote_path you configured, including glob expansion if you use it.
• A wrong private key path or stale password can fail the deployment even when the host is reachable.
• The no files found symptom usually points back to path selection or user permissions, not to a mysterious parser error.

How Skippr Handles It

Skippr keeps SFTP deploy checks grounded because the source boundary is concrete: one host, one auth method, and one remote path. That gives you a direct way to prove the source instead of relying on a generic SSH availability check.

It also supports a sensible production pattern. You can prefer private-key auth for long-lived pipelines while still validating the same thing after deploy: the runner can log in and read the intended files.

• Supports password or private-key authentication with the same narrow connector surface.
• Keeps remote_path explicit so the file boundary is visible in review.
• Makes the first post-deploy test a real file read rather than an SSH-only test.
• Lets you start with one small export path before widening the file set.

What the First Useful Version Looks Like

Choose a remote path that contains one or two stable files so the first validation is easy to inspect. Broad globs make the first failure signal harder to interpret.

If the runner cannot read that small path yet, fix auth or path access first. Wider file patterns will fail for the same underlying reason.