How to monitor FTP and SFTP uptime
Backups, deploys, EDI feeds and client file drops all depend on an FTP/SFTP server being reachable and accepting logins. Here's how to monitor that it actually is.
File transfer is the plumbing nobody watches. Nightly backups push over SFTP, a partner drops EDI files on a schedule, a legacy deploy still uses FTP, a client uploads assets. When the server is down or refusing logins, nothing errors loudly — the transfer just doesn't happen, and you find out when a backup is missing or a partner complains a file never arrived. Monitoring FTP/SFTP turns a silent gap into an immediate alert.
A port check isn't enough
Pinging port 21 or 22 tells you something is listening — not that it will let you in. Credentials expire, an account gets locked, disk fills up, an SSH key rotates, a host-key changes. A real check has to connect and authenticate, the way the job that depends on it does. That's the difference between "the port is open" and "the transfer will succeed."
Setting it up in MonitorSpider
MonitorSpider has dedicated FTP and SFTP monitor types. You provide:
- The host and port (21 for FTP, 22 for SFTP by default).
- A username and password for a monitoring account.
- For SFTP, whether to accept the host key as-is (
sslIgnore) if you're not pinning it.
Each interval it opens a connection and authenticates. If the server is unreachable, refuses the connection, or rejects the login, the monitor goes ERROR and alerts you — by email on any plan, or Slack/Telegram/webhook on Premium. The check also records response time, so a server that's getting slow to accept connections shows up before it fails outright.
Use a dedicated, low-privilege account
As with login monitoring, don't point the check at a powerful account. Create a monitoring user with minimal rights (ideally read-only, chrooted to an empty or throwaway directory). You're testing reachability and authentication, not doing real work — the account needs to log in, nothing more. This keeps credentials in your monitor low-risk and avoids tripping security controls.
What to watch
- The SFTP endpoint your backups push to — a missing backup you don't know about is the worst kind.
- Partner / EDI drop servers on both ends of a scheduled feed.
- Any FTP server still in a deploy pipeline — legacy, easy to forget, breaks quietly.
- Client upload endpoints you're responsible for keeping available.
Fewer false alarms
Transient connection blips happen. MonitorSpider debounces status changes — it waits for two consecutive failed checks before paging you, and only sends a recovery alert if it actually alerted on the failure — so one dropped connection at 3am doesn't wake you.