Email and Service Monitoring | Spark Uptime Documentation

Website uptime is not limited to HTTP and HTTPS. Many production systems depend on other network services, including mail servers, API endpoints, databases, control panels, and custom TCP services. If a port is closed, filtered, overloaded, or refusing connections, the service may be unavailable even when the server itself is still online.

Spark Uptime service monitoring can help verify whether a TCP port is reachable from the outside. This is useful for confirming that important services are listening, reachable through firewalls, and available from external monitoring locations.

Service monitoring principle TCP monitoring checks whether a port can be reached. It confirms network-level availability, but it does not replace application-level testing, login testing, database query testing, or full protocol validation.

On this page

What service monitoring checks
Common TCP ports
Email service monitoring
API monitoring
Database monitoring
Common failure causes
Best practices

What service monitoring checks

A TCP service check attempts to connect to a hostname or IP address on a specific port. If the connection succeeds, the service is considered reachable at the network layer. If the connection times out, is refused, or cannot be routed, the monitor can identify that the service may be unavailable.

The monitor connects to the target

Spark Uptime attempts to reach the configured hostname or IP address on the selected TCP port.

The connection result is evaluated

A successful connection means the port is externally reachable. A timeout, refusal, DNS failure, or route failure can indicate a service or network issue.

An alert can be sent

If the service becomes unreachable, Spark Uptime can notify your configured alert channels so you can investigate quickly.

Common TCP ports to monitor

The correct port depends on the service you operate. These are common TCP services that website owners, hosting providers, developers, and infrastructure teams may want to monitor.

Service	Port	What it usually means
HTTP	80	Unencrypted web traffic and HTTP validation endpoints.
HTTPS	443	Encrypted website and API traffic over TLS.
SMTP	25	Server-to-server email delivery.
SMTP Submission	587	Authenticated outbound email submission.
SMTPS	465	SMTP over implicit TLS.
IMAP	143	Email mailbox access without implicit TLS.
IMAPS	993	Email mailbox access over implicit TLS.
POP3	110	POP mailbox access without implicit TLS.
POP3S	995	POP mailbox access over implicit TLS.
SSH	22	Secure shell access for administration.
SFTP	22	File transfer over SSH.
FTP	21	Legacy file transfer control port.
MySQL / MariaDB	3306	Database access for MySQL-compatible servers.
PostgreSQL	5432	Database access for PostgreSQL servers.
Microsoft SQL Server	1433	Database access for Microsoft SQL Server.
Redis	6379	Cache, queue, and key-value data service.
MongoDB	27017	MongoDB database service.
Elasticsearch	9200	Search and indexing API endpoint.
cPanel	2083	Secure cPanel user interface.
WHM	2087	Secure WHM administration interface.
Plesk	8443	Plesk hosting control panel.

Security note Only expose ports publicly when they are intended to be public. Many databases, caches, and admin services should be restricted by firewall rules, VPN, private networking, or trusted IP allowlists. Monitor only what should be externally reachable.

Email service monitoring

Email systems depend on several services. A mail server may be able to send mail but fail mailbox access, or receive mail but fail authenticated submission. Monitoring the right ports helps identify which part of the mail stack is affected.

SMTP deliveryMonitor TCP 25 when you operate an inbound mail exchanger that receives mail from other mail servers.

SMTP submissionMonitor TCP 587 or 465 when users or applications submit authenticated outbound mail.

IMAP accessMonitor TCP 993 when users access mailboxes from email clients using secure IMAP.

POP accessMonitor TCP 995 when users retrieve mail using secure POP3.

TCP monitoring can confirm that these ports are reachable, but email deliverability also depends on DNS records, reputation, SPF, DKIM, DMARC, reverse DNS, mail queue health, spam filtering, and provider policies.

API monitoring

APIs are commonly served over HTTPS on TCP 443, but some internal or specialized APIs may use custom TCP ports. For public APIs, use HTTPS monitoring when you need to verify the actual HTTP response, status code, content, or keyword. Use TCP monitoring when the main question is whether the port is reachable.

Monitoring type	Best for
HTTPS monitor	Checking API status codes, TLS validity, response time, redirects, and expected response content.
TCP port monitor	Checking whether a custom API listener or service port is reachable from outside.

For important APIs, monitor both availability and behavior. A port can be open while the API still returns 500 errors, invalid JSON, authentication failures, or dependency-related errors.

Database monitoring

Database port monitoring can confirm whether a database listener is reachable. This is useful for private infrastructure checks, controlled networks, and cases where a database endpoint is expected to accept connections from specific locations.

For public websites, databases normally should not be exposed to the entire internet. If a database port must be reachable, restrict it to trusted IP addresses, use strong authentication, require encryption where supported, and monitor access attempts.

Database monitoring guidance Monitoring TCP 3306, 5432, 1433, 6379, 27017, or similar ports only verifies network reachability. It does not confirm query performance, replication health, disk space, locks, slow queries, or application-level database correctness.

Common service monitoring failures

Failure	Common cause	What to check
Connection refused	The server is reachable, but nothing is listening on the port.	Service status, port binding, container mapping, and process logs.
Connection timeout	The port may be filtered, firewalled, overloaded, or unreachable.	Firewall rules, security groups, routing, provider network status, and server load.
DNS failure	The hostname does not resolve or resolves inconsistently.	A, AAAA, CNAME, nameservers, DNSSEC, and resolver behavior.
Intermittent failures	Multiple backends, unstable network path, rate limiting, or resource exhaustion.	Load balancer health, backend logs, limits, and regional failures.
Works locally but fails externally	The service may only be available from inside the server or private network.	Listen address, NAT, firewall, public IP routing, and allowlists.

Best practices

Monitor public website and API endpoints with HTTP or HTTPS checks when you need application-level validation.
Use TCP port monitoring for services where network reachability is the primary signal.
Monitor email ports separately because SMTP, submission, IMAP, and POP can fail independently.
Do not expose database, cache, or admin ports publicly unless there is a clear operational reason.
Use firewalls, VPNs, private networks, or trusted IP allowlists for sensitive services.
Document the purpose of each monitored port so alerts are easy to understand.
Investigate both the service process and the network path when a port fails.
Review DNS and SSL/TLS separately when the service uses hostnames or encrypted connections.

Operational takeaway TCP service monitoring is a fast way to know whether important ports are reachable. Pair it with HTTP, HTTPS, DNS, SSL/TLS, and application monitoring for a complete reliability picture.

Create Account Previous: Website Performance