- Product · Internet Infrastructure Monitoring
FTP Monitoring Software for Servers & Files
Dotcom-Monitor’s FTP monitoring tool does what your file-transfer partners and batch jobs do, on a schedule: it connects to your FTP, SFTP or FTPS server, logs in with real credentials, lists the directory, confirms the files you name are there, and runs a test transfer. Every step is timed and compared with your response-time threshold.
If any step fails, from a refused connection to a missing nightly export, the check is re-run from a second monitoring location and the alert goes to your on-call channel with the error attached.
Connect, log in, list, check files, transfer. Alert on any failure.
All three protocols in one task type
Connect, login, list, file check, test transfer
Shortest check interval
Monitoring locations, or your own private agent
What FTP Monitoring Is, and What Ours Does
FTP monitoring is the automated, repeated checking that a file transfer server accepts connections, authenticates users, exposes the expected directories and files, and completes transfers within an acceptable time. Dotcom-Monitor’s FTP monitoring software does this synthetically: on the interval you set, a monitoring agent behaves like an FTP client, performs the same sequence a partner or a scheduled job would (connect, log in, list, check for files, transfer a test file), records the result and the response time, and alerts you when any step fails or runs past your threshold.
FTP server monitoring, SFTP monitoring and FTPS monitoring are one task in Dotcom-Monitor. It covers plain FTP (RFC 959), FTPS (FTP over TLS, explicit or implicit) and SFTP (file transfer over SSH), so one tool monitors the legacy server a vendor still uses, the FTPS endpoint your bank requires and the SFTP host your own integrations run on. If your server is reachable only from inside your network, the same check runs from a private agent installed behind your firewall.
Where this fits among the other kinds of “FTP monitoring”. Some products put an agent on the FTP server and watch CPU, disk and the FTP service’s counters. Others only confirm that port 21 answers. This page is about the third kind: an external, client-side check that proves the server works for the people and systems that depend on it. The comparison table below shows when each one is the right tool, and why a port check alone misses most FTP failures.
How an FTP Monitoring Check Runs
Each check is a short FTP session between a Dotcom-Monitor agent and your server. The agent runs only the steps you enable, times the whole session, and repeats on the interval you set, as often as every minute.
The agent is the client. Nothing is installed on your FTP server, and the check uses the same ports, encryption and credentials your partners use.
The Agent Resolves the Hostname and Opens the Connection
You give it a hostname or IP, with a port if the server does not use the default (ftp.example.com:2121). For FTPS the agent negotiates TLS, explicit (AUTH TLS on port 21) or implicit (port 990), or works it out automatically; for SFTP it opens an SSH session on port 22. A refused connection, a failed handshake or an unexpected banner is an error on its own.
It Logs In, If You Tell It To
With Login to Server off, the check confirms only that the server answers on the address and port. With it on, the agent authenticates with the username and password you provide, which can be stored in Secure Vault instead of the task. Key-based SFTP authentication with a client certificate is supported too. Anonymous FTP is simply a login with the anonymous account.
It Lists the Directory
With Directory Listing on, the agent changes to the directory you specify and requests a listing. This is where permission problems, a renamed folder and a home directory that no longer exists show up.
It Checks That Your Files Are There
Name up to three files or patterns that must appear in the listing; * and ? wildcards are accepted, so export_*.csv matches whatever today's export is called. A file that is missing fails the check. This is how you find out the overnight job did not deliver, before the partner who was waiting for it does.
It Runs a Test Transfer
The agent can upload a small test file to the directory, and download a file you name (the first 2 MB, enough to prove the data path works without moving a large file every minute). A transfer that stalls, is refused or exceeds the threshold is recorded as an error with the server's response code.
The Result Is Timed, Verified and Alerted
The whole session is compared with your Time Validation Threshold; a slow server fails just like a down one. Before an alert is sent, the platform re-runs the failed check from another monitoring location. If that one also fails, the alert goes out through your alert rules (email, SMS, phone call, Slack, Microsoft Teams, PagerDuty, webhooks) with the error code and the failing step. If it succeeds, the event is logged and nobody is paged.
Every Setting in the FTP Task, and What It Verifies
An FTP monitoring task is one device in your Dotcom-Monitor account, configured with the same details you would put into an FTP client: host and port, protocol and encryption, credentials, the directory to look in, and the files that must be there. Enable only the steps you need; a connect-only task on a public anonymous server and a full login-list-transfer task on a partner SFTP host are the same task type with different boxes ticked. The full field reference is in the knowledge base: Configure an FTP, SFTP or FTPS Task.
- Connection check. Proves the server is up and reachable on the configured port, with the encryption your clients use.
- Login check. Proves the account still works: not expired, not locked, password not rotated without telling anyone.
- Directory and file checks. Prove the path exists, is readable, and contains the files a downstream process is waiting for.
- Transfer check. Proves the data connection works end to end, which is the part a port check never sees.
- Response-time threshold. Flags a server that still answers but has become too slow for your batch window.
The FTP task settings, as an illustration: the same fields you would fill in an FTP client, plus the files that must be present.
Setting | What You Enter | What It Lets the Check Verify |
|---|---|---|
Hostname / Port | Domain or IP of the server; add :port if it is not the protocol default (21, 22 or 990) | Reachability of the server on the port your clients use, including non-standard ports |
Protocol | FTP, SFTP (FTP over SSH) or FTPS (FTP over TLS) | The same transport as the clients, not a plaintext stand-in |
Encryption | Auto, None, TLS/SSL explicit or TLS/SSL implicit | The TLS handshake and certificate on an FTPS endpoint; an expired certificate fails the check |
Transfer Mode | Active or passive | That the data connection works the way your firewall is configured for; passive-mode port ranges are the usual culprit |
Login to Server | Off for a connect-only check; on with User Name and Password | The account authenticates; credentials can be referenced from Secure Vault |
Client Certificate | A key for certificate or key-based authentication (RSA, DSA, ECDSA, ED25519), installed by our support team | Key-based SFTP or certificate-based FTPS logins, the way automated partners connect |
Directory Listing / Directory | On, plus the path to list | The directory exists and the account has permission to read it |
Check File 1–3 | Up to three file names or patterns, with * and ? wildcards | The expected files are present; a missing export or feed fails the check |
Download File | On, to retrieve the first 2 MB of a named file | The data channel works and the file is readable, without moving large files every interval |
Upload Test File | On, to write a small test file to the directory | Write permission and free space on the target, which a download check cannot prove |
Time Validation Threshold | Maximum seconds for the session to complete | Slow servers are flagged before they become failed ones |
DNS Options | Resolver mode, custom DNS server, custom host-to-IP mappings; IPv4 and IPv6 | Tests through the name your clients resolve, including an internal name via a private agent |
FTP, FTPS and SFTP: What Each One Is, and What the Check Does Differently
The three names look alike and get mixed up in tickets every day. They are different protocols, they use different ports, and they fail in different ways. One Dotcom-Monitor task type covers all three; here is what changes under the hood.
FTP | FTPS FTP Over TLS | SFTP SSH File Transfer Protocol | |
|---|---|---|---|
What It Is | The original protocol (RFC 959): a control connection on port 21 and a separate data connection per transfer; everything in plaintext | FTP with the control and data connections wrapped in TLS. Explicit starts plain on port 21 and upgrades with AUTH TLS; implicit is TLS from the first byte on port 990 | A different protocol that runs over an SSH session on port 22, usually with a single connection and often with key-based authentication |
Default Port | 21 (control) + a data port | 21 explicit / 990 implicit + a data port | 22 |
Typical Failure | Passive data port range blocked by a firewall; login works but the listing hangs | Certificate expired or renewed with the wrong chain; clients refuse the handshake | Host key changed after a rebuild; account’s key removed; SSH service down while port 22 still answers |
What the Check Adds | Active or passive mode selectable, so the test matches how your partners connect | TLS negotiation, explicit or implicit or auto-detected; a bad certificate fails the check | SSH session and authentication, with password or client key |
Then, for All Three | Login, directory listing, up to three file checks, test upload and 2 MB test download, timed against your threshold. Same settings, same alerts, same reports. | ||
FTP Server Monitoring: Failures a Scheduled Client-Side Check Catches
FTP failures are quiet. Nobody sees a 500 page; a job runs with yesterday’s file, a partner’s upload silently fails, and the first signal is a reconciliation that does not add up. A scheduled check surfaces these first.
Server Down or Port Blocked
The service crashed, the host rebooted without it, or a firewall rule change cut the path from one region. The connect step fails on the next check, from every location that is affected.
Login Rejected
A rotated password that was not updated on the client side, an expired or locked account, a removed SSH key. The server is up, the port answers, and nobody can get in. The login step reports the 530 (or the SSH authentication failure) with the check.
Passive Data Ports Blocked
The classic FTP failure: the control connection and login succeed, then the listing hangs because the firewall does not allow the passive port range. A port monitor says everything is fine. The listing step times out and tells you otherwise.
Expired FTPS Certificate
The certificate on the FTPS endpoint expires or is renewed with an incomplete chain, and every TLS client starts refusing the handshake. The check fails at the connection step with the TLS error.
The Nightly File Did Not Arrive
The export job failed, wrote to the wrong folder, or is still running. A file check for export_*.csv in the outbound directory fails, and the alert reaches you before the partner’s morning import does.
Permissions and Paths Changed
A home directory moved, a folder was renamed in a migration, a permission reset left the account unable to read or write. Listing and transfer steps catch what the login step cannot.
Disk Full or Writes Refused
The upload test file is refused with a 452 or 552 because the volume is full or quota is exhausted. Downloads still work, so a read-only check would pass; the upload step does not.
Slow Transfers
Everything completes, but well past your threshold: a saturated link, a struggling disk, a server under load. Threshold errors appear in the report before the batch window is missed.
File Age and File Size Checks on an FTP Server
The built-in task answers “is the file there?”. Some workflows need “is the file fresh?” and “is it the right size?”: a feed that is overwritten daily will always exist, and a zero-byte export is worse than no export. For those, Dotcom-Monitor provides a ready-made custom script device, documented in the knowledge base as Monitoring FTP Files by Timestamp and Size, that logs in over FTP, SFTP or FTPS and checks the file’s age and size against limits you set.
- Maximum age in minutes. Fail if the file's last-modified time is older than, say, 90 minutes. "Alert if the 6 a.m. export has not been refreshed by 7 a.m." becomes one monitoring device.
- Minimum and maximum size in bytes. Catch the empty file and the runaway one.
- Optional download. Pull the file (up to 2 MB) to confirm it is readable, not just listed.
- Time zone offset. Compare the server's timestamps correctly when it sits in another zone.
Illustrative argument set for the sftp_file_check custom script. The exact syntax is in the knowledge base article.
Through Your Firewall, or From a Private Agent Inside It
Like any FTP client connecting from outside, the monitoring agent needs to reach the control port and, for FTP and FTPS, the data ports. Dotcom-Monitor’s monitoring locations have published IP addresses; allowlist the ones you use on a server that restricts logins by source. Running the task from more than one location shows whether a failure is specific to one network path or affects every client, which is also the evidence you need when a partner says “it works from here”.
If the server is not exposed to the internet, install a private agent: the monitoring software on a Windows machine inside your network. The Protocol Edition is enough for FTP, SFTP and FTPS tasks. It runs the same check against internal names and addresses, appears in your account as another location, and reports into the same dashboards and alerts. Running one public location and one private agent against the same server separates “the FTP server is down” from “the path to the FTP server is down”.
Verified Alerts and Uptime Reports for Every FTP Server
Verified Alerts, With the Failing Step
A single failed check from one location may be one bad route, not an outage. Dotcom-Monitor re-runs a failed task from another location before opening an incident. Only a confirmed failure reaches your alert channels: email, SMS, phone call, Slack, Microsoft Teams, PagerDuty, ServiceNow, SNMP traps and webhooks, routed through escalation schedules so the next person is paged if the first does not respond. The alert names the step that failed (connection, login, listing, file check or transfer), the server’s error code and the response time, and includes a traceroute from the agent to the host.
Uptime and Response-Time Reports
Every check writes a status and a response time into your reports and dashboards: uptime percentage for the period, response-time trend per location and an error log with the server’s response for each failure. That is the record to bring to a hosting provider or a managed file transfer vendor when their SLA says 99.9% and your data says otherwise.
Everything the Platform Gives Every Monitor
- Scheduling from every minute to every 15 minutes per task, with maintenance windows so a planned server migration does not page anyone.
- Filters that require a failure to repeat, or to occur from N locations, before an alert fires.
- Reports and dashboards shared with your team, or white-labeled for the clients of an MSP.
- REST API to create an FTP task for every server and partner endpoint from a script, and to pull results into your own tooling.
- Secure Vault for FTP passwords: stored encrypted, masked in the UI and never shown in reports.
- One account for FTP alongside DNS, SSL, port, ping, email and website monitoring. A file-transfer outage and a DNS outage appear on the same status board.
FTP Monitoring vs Port Monitoring vs Server-Side FTP Monitoring
Three different things get sold as “FTP monitoring”. They answer different questions, and a port check in particular is often mistaken for the real thing. The table shows where each fits and which one this page covers.
Client-Side FTP Monitoring This Page · Dotcom-Monitor | TCP Port Monitoring Dotcom-Monitor Port Task or Any Uptime Tool | Server-Side FTP Monitoring Agent Installed on the FTP Server · Not Dotcom-Monitor | |
|---|---|---|---|
Question It Answers | Can a client connect, log in, see the files and transfer data right now, from where our partners are? | Is something accepting TCP connections on port 21, 22 or 990? | How is the server itself doing: CPU, disk, FTP service counters, session counts? |
How It Tests | Scheduled FTP/SFTP/FTPS client session: connect, login, LIST, file checks, test upload and download, timed | TCP handshake to the port, optionally reads the banner | Agent or SNMP/WMI polling on the host; log parsing |
What You Need | Hostname, port, credentials; monitoring IPs allowlisted or a private agent | Hostname and port | Agent installed on each server, or management access to it |
Catches | Down servers, rejected logins, blocked data ports, bad certificates, missing files, full disks, slow transfers | Down servers; a blocked control port | Resource exhaustion, capacity trends, who logged in and when |
Misses | Internal server metrics (CPU, disk usage trends), individual user activity | Everything after the handshake: logins, listings, data connections, file presence | Whether the server is reachable and usable from outside; partner-side failures |
Best For | Teams responsible for file exchanges with partners, EDI/MFT endpoints, batch pipelines and hosted FTP services | A cheap heartbeat on a server you also monitor another way | Sysadmins managing the FTP host itself |
Get It | Port monitoring (same plan) | Separate product category |
Rated by the Teams Who Run It
“I’m a network analyst and use Dotcom tools inside the ISP I work, it’s a really good and reliable tool for monitoring things along the network, and testing network components, I usually use it to make diagnostics of servers latency, and dns resolve time.”
“One of Dotcom’s best features is the push/pull API capabilities that provide us with network performance data. We use this to monitor for performance issues as well as page loading stats. Dotcom-Monitor allows us to monitor multiple services within one interface and platform. It’s allowed us to operate more efficiently.”
Gregory S. · Manager, Broadcast Media · Verified Capterra review, May 2020
4.6 Customer service
All reviews sourced from Capterra verified reviews. Ratings as of October 2026.
FTP Monitoring Is Part of the Internet Infrastructure Plan
FTP, SFTP and FTPS tasks are billed under Internet Infrastructure (ServerView), the same plan that covers DNS, SSL certificate, port, ping, traceroute, email server and VoIP checks. One target is one FTP task; mix FTP targets with any of the others in the same plan. Every plan includes alerting, reports and the API.
- 5 to 300 targets per plan
- Check intervals from 15 minutes down to 1 minute
- Private agents available for servers behind a firewall
- 30-day free trial with full platform access, no credit card
Port Monitoring
SSL Certificate Monitoring
Private Agents
FTP Monitoring Questions
What Is FTP Monitoring?
FTP monitoring is the automated, repeated checking that a file transfer server accepts connections, authenticates users, exposes the expected directories and files, and completes transfers within an acceptable time. Dotcom-Monitor does it synthetically: a monitoring agent acts as an FTP client, performs the connect, login, listing, file-check and transfer steps on a fixed interval, records the result and response time, and alerts on any failure. Some products use the same term for an agent on the server that watches CPU, disk and service counters; that is a different tool, described in the comparison table.
What Does FTP Monitoring Software Actually Check?
An FTP server monitoring tool should test the server the way a client uses it. With Dotcom-Monitor, that is up to five things per check, each one optional: that the server accepts a connection on the configured port with the configured encryption; that the login succeeds; that a directory listing can be retrieved; that up to three named files or wildcard patterns are present; and that a test transfer works, by uploading a small test file and by downloading the first 2 MB of a file you name. The whole session is timed against your threshold, and any failed step or timeout is an error.
Does It Monitor SFTP and FTPS as Well as FTP?
Yes. One task type covers plain FTP, FTPS (FTP over TLS, explicit on port 21 or implicit on port 990, or auto-detected) and SFTP (file transfer over SSH on port 22). The login, listing, file-check and transfer steps are the same for all three; what changes is the transport and the authentication, including client certificates or keys for FTPS and SFTP.
Can I Monitor an FTP Server on a Non-Standard Port?
Yes. Add the port to the hostname, for example ftp.example.com:2121 or sftp.example.com:2222. Without a port, the check uses the protocol default: 21 for FTP and explicit FTPS, 990 for implicit FTPS, 22 for SFTP.
Does It Support Active and Passive Mode?
Both, selectable per task for FTP and FTPS. Passive mode is the usual choice when the server sits behind a firewall or NAT, because the client opens the data connection to a port the server announces; active mode has the server connect back to the client. Matching the mode your partners use means the check fails the way their transfers would fail, which is the point. A blocked passive port range is the most common reason a login succeeds and the listing hangs.
Does the Check Upload or Download Real Files?
It can do both, and you choose. The upload step writes a small test file to the directory, which proves write permission and free space. The download step retrieves the first 2 MB of a file you name, which proves the data channel and that the file is readable, without moving a large file every minute. If you only want presence checks, leave both off and use the file checks.
How Do I Get Alerted When an Expected File Has Not Arrived?
Enter the file name, or a wildcard pattern such as export_*.csv, in one of the three Check File fields, with Directory Listing on and the directory set. If the listing does not contain a match, the check fails and an alert is sent. If the file always exists but you need to know it was refreshed, use the file age and size custom script, which fails when the file is older or smaller than the limits you set.
What Metrics Does an FTP Check Report?
Each check records a status (success or the error code and failing step) and the total response time for the session, from each monitoring location. Reports show uptime percentage, response-time trends per location and the error log. The check does not report per-step timings or a transfer rate; its purpose is to confirm that the server works for a client and to time the whole operation against your threshold.
Can I Monitor an FTP Server That Is Not Exposed to the Internet?
Yes, with a private agent: the monitoring software installed on a Windows machine inside your network. The Protocol Edition covers FTP, SFTP and FTPS. It runs the task against the internal name and address, appears in your account as an additional location, and feeds the same reports and alerts. The DNS Options setting can map a hostname to an internal IP when the name does not resolve publicly.
How Often Does It Check, and From Where?
As often as every minute and as seldom as every 15 minutes, per task. Each task runs from the Dotcom-Monitor monitoring locations you select, from a private agent inside your network, or both. Each location reports its own result and response time, so a failure from one region and a failure from everywhere look different in the report.
What Happens When a Check Fails?
The failure is recorded with the step, the server’s response and the timing, and the platform re-runs the task from another location. If the second location also fails, an alert is sent through your configured channels (email, SMS, phone call, Slack, Microsoft Teams, PagerDuty, ServiceNow, SNMP, webhooks) following your escalation schedule, with the detail from each location and a traceroute attached. If the second location succeeds, the event is logged as a single-location error and nobody is paged.
Is a Port Check on Port 21 Enough to Monitor FTP?
No. A port check proves that something accepts TCP connections on port 21, 22 or 990; it stops before the login. Most FTP failures happen after that point: a rejected password, an expired FTPS certificate, a passive port range the firewall blocks, a directory the account can no longer read, a file that did not arrive, a full disk. The FTP check exercises each of those steps. A port check is still a useful heartbeat beside it, and both are targets in the same plan.
Is There a Free FTP Monitoring Tool?
Open-source and command-line tools are useful for a one-off test from a workstation. They lack scheduling, execution from multiple locations, verified alerting, history and reports. Dotcom-Monitor offers a 30-day free trial with full platform access and every check type, with no credit card. That is the fastest way to see whether a scheduled client-side check catches the failures you care about.
How Much Does FTP Monitoring Cost?
FTP, SFTP and FTPS tasks are part of the Internet Infrastructure plan, which starts at $40 per month for 5 targets and scales to 300 targets, with check intervals from 15 minutes down to 1 minute. A target is one FTP task. The same plan covers DNS, SSL, port, ping, traceroute, email and VoIP checks, so a handful of FTP endpoints rarely needs a plan of its own. Current tiers are on the pricing page.
Start Monitoring Your FTP, SFTP and FTPS Servers
Start a 30-day free trial, add an FTP task with your server, a monitoring account and the files that must be there, and see the first results within minutes. No credit card required.