Documentation
Complete guide to setting up website monitoring with PingZen. API documentation, code examples, and best practices.
An FTP monitor connects to your file server, logs in with the user and password you give it (anonymous if you give none), asks the server which directory the session landed in, and logs out. It is a login check, not a file check: nothing is listed, downloaded or uploaded.
What It Is For
A file drop that partners or customers upload to
Exchange folders break at the login, not at the port. A password expires, an account is disabled, the home directory disappears, the auth backend stops answering — and the port stays open through all of it. The monitor completes the same login your partner does, so you hear about it before they email you.
A public or anonymous FTP mirror
Leave the user and password empty and the monitor logs in as anonymous with the password anonymous@ — exactly what an anonymous client sends. If the server stops accepting anonymous users, that shows up as a failed check instead of a support ticket.
A server behind a firewall, NAT or an allow-list
A check from a PingZen region reaches the server the way an outside client does, so a rule that quietly stops letting anyone in becomes visible. To see the same server from inside your own network, run the monitor from a private probe.
Proving the service really came back after a restart
An FTP daemon can accept connections long before it can serve accounts. Because the check goes all the way through login and one command, a server that greets you and then refuses every user is recorded as down — a plain port check on 21 would call it healthy.
What It Is Not For
This monitor speaks FTP and nothing else, and it stops right after logging in:
| You want to know | Use instead |
|---|---|
| Is my SFTP server up? SFTP is not FTP — it is a subsystem of SSH on port 22, a completely different protocol. This monitor cannot talk to it, and neither can any other PingZen monitor | TCP monitor on port 22, which proves SSH accepts connections — the closest check available |
| Did last night's file arrive, and is it the right size? The check runs no listing and transfers no data, so an empty or stale folder still passes | Heartbeat monitor — have the job that writes the file call its URL after a successful upload |
| When does the certificate on my FTPS server expire? | TLS/SSL certificate monitor on the implicit-TLS port, normally 990 — the FTPS check encrypts the login but does not validate the certificate, and the certificate monitor cannot send AUTH TLS, so it needs a port that answers TLS directly |
| Is the port open at all? You have no account, or you would rather not leave a login attempt in the server's auth log every minute | TCP monitor on port 21, which connects and disconnects without logging in |
| Is the web file manager or the download page working? | HTTP / HTTPS monitor |
What the Check Does
- Connects to the host and port — port 21 unless your address says otherwise. On port 990 the connection is TLS from the very first byte, before anything is read.
- Reads the server greeting.
- On any other port, upgrades an encrypted check in place: sends
AUTH TLS, and everything after this point travels inside TLS. - Sends the login:
USER, thenPASS. - Sends one command,
PWD, and reads the directory the session started in. This is the proof that the session is real and not just a socket. - Sends
QUITand closes the connection.
That is the whole check. No directory listing, no file download, no upload, no data connection at all — which also means passive mode and the data-port range are never exercised.
The response time covers the connection, the login and the PWD reply. The directory the server reported is attached to the check result, but it is not kept in check history and no screen displays it, so treat it as an internal detail rather than a feature.
FTP, FTPS and the Difference That Matters
FTPS comes in two shapes, and they are not interchangeable:
- Explicit FTPS connects in the clear on port 21 and then upgrades the session with the
AUTH TLScommand. - Implicit FTPS expects TLS from the very first byte, normally on port 990, the way HTTPS does.
Both are supported, and the port decides which one is used: port 990 gets implicit TLS, every other port gets explicit TLS. Nothing to configure — an FTPS monitor is always encrypted, and a plain FTP monitor is encrypted when its “Use TLS (FTPS)” box is ticked.
Explicit is the right default for almost everyone. It is what FileZilla Server, vsftpd and ProFTPD enable out of the box, and implicit FTPS on 990 is the older shape kept alive mostly by appliances. If you are not sure which your server speaks, leave the port alone and let the monitor use explicit.
What TLS Here Does and Does Not Prove
- The login is encrypted. The username and password travel inside the TLS session, and a server configured to refuse cleartext logins will accept this check.
- The certificate is not validated. Self-signed certificates are the norm on file servers — NAS boxes and FileZilla Server generate one on first run — so refusing them would fail nearly every real FTPS server. The check answers “is the service up and does it authenticate”, and certificate trust is a separate question. To watch the certificate itself, add an TLS/SSL certificate monitor, which needs an implicit-TLS port such as 990 because it cannot send
AUTH TLSof its own. - The data channel is never tested.
PBSZandPROTare not sent, because this check opens no data connection. A server can pass this check and still be misconfigured for encrypted transfers.
Status Logic
An FTP monitor has no degraded state. Each check is up, down or timed out.
| Result | Status |
|---|---|
Login accepted and the server answered PWD | UP |
| The server refused the login or any other command — the error message carries its reply code and text, such as a 530 for a wrong password | DOWN |
| The connection was refused — nothing is listening on that port | DOWN |
| The hostname did not resolve, the route failed, or the connection was reset | DOWN |
The TLS handshake failed, or the server refused AUTH TLS — it is not an FTPS server on that port | DOWN |
Connect, login and PWD did not finish inside the timeout | TIMEOUT |
Down and timeout both count as downtime and open an incident once the confirmation threshold is reached — three consecutive failing checks by default, so one refused login during a restart does not page anyone.
A wrong password is worth a word of warning. To the monitor it is indistinguishable from an outage: the server answers, rejects the login, and the check goes red. Many FTP servers also ban an address after a few failed logins, so a monitor with stale credentials can lock itself out and then report a real-looking outage. Update the monitor whenever you rotate that account’s password.
Configuration
Address
The host, with an optional port: files.example.com or files.example.com:2121. An ftp:// or ftps:// prefix is accepted and stripped, and IPv6 goes in brackets. Without a port the check uses 21, for both the FTP and the FTPS type. There is no separate port field on this form — the port lives in the address.
Username and password
Both optional. Empty username means anonymous, empty password means anonymous@. The password is stored write-only: the API reports whether one is set, never its value. Do not put credentials in the address as ftp://user:pass@host — that form is rejected, because a URL ends up in responses, alerts and logs.
Use TLS (FTPS)
Shown on FTP monitors only, where it turns the check into explicit FTPS — the same thing an FTPS monitor does. An FTPS monitor has no such box because it is always encrypted. The server certificate is not validated either way; see above.
Timeout
Five seconds by default, and it covers the whole exchange — connect, greeting, login and PWD. That is a short budget for a busy or distant FTP server, which answers each command in its own round trip; 10 to 15 seconds is a more realistic setting than it is for a plain port check.
Both monitor types read the same three settings, so an FTP monitor with the TLS box ticked and an FTPS monitor are the same check.
Key Features
- A real login, not a port probe: connect,
USER,PASS,PWD,QUIT - FTPS in both shapes: explicit
AUTH TLSon any port, implicit TLS on 990 - Anonymous and credentialed logins both supported; empty fields mean anonymous
- Passwords are stored write-only and never returned by the API
- The server’s own reply code and text land in the error message, so a 530 login failure is not confused with an unreachable host
- Custom port straight in the address, and checks from any region or private probe
- Standard alerts and incidents, with the usual three-failure confirmation
Common Questions
What protocols can I monitor?
PingZen supports 23 protocols: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL certificates, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check, and Transaction. You can monitor websites, APIs, servers, databases, and any network service.
How fast can I get alerts?
Telegram alerts are delivered within 1-2 seconds of detection. Slack and Discord notifications arrive almost instantly. You can configure multiple alert channels for redundancy.
Can I organize monitors by project?
Yes! PingZen supports workspaces, which let you organize monitors by project, environment, or team. Each workspace can have its own alert configurations and team members.
Is there an API for automation?
Absolutely. PingZen provides a full REST API with OpenAPI documentation. You can create, update, and delete monitors programmatically.
How do status pages work?
Status pages are public, branded pages showing your services' uptime. You can display real-time status and allow customers to subscribe for updates.
What happens if I reach my monitor limit?
We'll notify you when approaching your limit. You can pause some monitors or contact us for increased capacity. We never stop monitoring without warning, ensuring your critical services stay protected.
Ready to stop missing downtime?
Join thousands of teams who trust PingZen. Setup takes 30 seconds.