How to Choose the Right Monitor Type | Spark Uptime Documentation

The best uptime monitor starts with the right check type. A website, API endpoint, IP address, open port, and page content requirement all answer different operational questions. Choosing the correct monitor type helps reduce noise, improve alert accuracy, and make incident investigation faster.

Spark Uptime supports four monitor types: Website, Keyword, Ping, and Port. Each type is designed for a specific kind of availability signal.

Recommended default For most homepages, business websites, ecommerce stores, landing pages, and public web applications, start with a Website monitor. It confirms that the URL is reachable over HTTP or HTTPS and provides the clearest customer-facing availability signal.

On this page

Monitor types
Website monitors
Keyword monitors
Ping monitors
Port monitors
Check frequency
Global checks and verified downtime
Decision guide

Spark Uptime monitor types

Monitor type	Best for	What it proves
Website	Homepages, stores, dashboards, APIs, status pages, and public URLs.	The URL is reachable and responding over HTTP or HTTPS.
Keyword	Pages where specific text must be present.	The page loaded and the required case-sensitive keyword was found.
Ping	IPv4 or IPv6 reachability checks.	The IP address or host responds to ICMP ping from the monitoring network.
Port	TCP services such as SMTP, SSH, database listeners, mail services, and custom application ports.	The selected TCP port from 1 through 65535 is accepting connections.

Website monitors

Website monitors are the best starting point for most customer-facing services. Use this type when you want to monitor a URL such as a homepage, store, login page, API endpoint, documentation site, or public status page.

Website monitors can be created with a URL that includes http:// or https://. They can also be entered without the protocol, depending on how you prefer to define the target. For most production websites, HTTPS should be used because it reflects what visitors and customers actually load.

How Website checks run Spark Uptime performs Website checks using an HTTP HEAD request. The check uses HTTP/2 when supported by the target server and falls back to HTTP/1.1 when HTTP/2 is not supported.

Use Website monitoring for

Main websites and marketing pages.
Ecommerce storefronts and checkout entry points.
Documentation, help centers, and customer portals.
Public API health URLs or lightweight API endpoints.
Status pages and hosted application pages.

Keyword monitors

Keyword monitoring is useful when the page must contain specific text. A website can return a successful response while still showing the wrong page, an error template, a maintenance message, or incomplete content. A Keyword monitor adds a content-level check on top of reachability.

Case-sensitive matching Spark Uptime Keyword monitors check for a case-sensitive keyword. Enter the keyword exactly as it should appear on the page.

Use Keyword monitoring when

A page must show a specific phrase, brand name, product name, or success message.
You want to verify that a page is serving real application content, not only returning a response.
You want to catch incorrect maintenance pages, default hosting pages, or unexpected application output.
You need a stronger signal than basic URL availability.

Ping monitors

Ping monitors check network reachability for an IPv4 or IPv6 address. They are useful when you want a simple signal that an IP address or host is reachable at the network layer.

Ping is not a replacement for Website monitoring. A server can respond to ping while the website, web server, database, or application is down. Likewise, some firewalls intentionally block ICMP ping even when the service itself is healthy.

Use Ping monitoring for

IPv4 or IPv6 reachability checks.
Network devices, routers, firewalls, and infrastructure endpoints that respond to ping.
Basic host availability where ICMP is intentionally allowed.
Supplemental infrastructure visibility alongside Website or Port monitors.

Port monitors

Port monitors check whether a specific TCP port is accepting connections. Use this type when the availability question is not “does the website load?” but “is this service port reachable?”

Spark Uptime Port monitors can check TCP ports from 1 through 65535. This is useful for monitoring mail services, SSH, database listeners, APIs behind custom ports, control panels, and other network-facing TCP services.

Service	Common TCP port	What to monitor
HTTP	80	Basic web service availability when HTTPS is not the target.
HTTPS	443	TLS web service availability at the TCP connection level.
SSH	22	Administrative access availability.
SMTP	25	Mail server-to-server SMTP availability.
SMTP submission	587	Authenticated outbound mail submission availability.
SMTPS	465	Implicit TLS SMTP submission availability.
IMAP	143	Mailbox access service availability.
IMAPS	993	IMAP over TLS availability.
POP3	110	POP mailbox access availability.
POP3S	995	POP over TLS availability.
MySQL or MariaDB	3306	Database listener availability when intentionally reachable from monitoring locations.
PostgreSQL	5432	Database listener availability when intentionally reachable from monitoring locations.
Redis	6379	TCP listener availability for managed or secured Redis endpoints.
Custom application	Any configured TCP port	Application-specific service availability.

Security reminder Only monitor ports that are intentionally exposed to the internet or reachable from Spark Uptime monitoring locations. Do not open database or administrative ports publicly just to monitor them. Use firewall rules, allowlists, VPNs, private networking, or managed service health endpoints where appropriate.

Choosing the right check frequency

Spark Uptime supports 1-minute, 5-minute, and 10-minute check intervals. Shorter intervals detect problems faster, while longer intervals reduce check volume and are often enough for lower-risk services.

Frequency	Best for	Guidance
1 minute	Critical production services, revenue-impacting pages, key APIs, and customer login flows.	Use when fast detection matters and a few minutes of downtime is operationally important.
5 minutes	Most business websites, stores, documentation sites, customer portals, and standard APIs.	Recommended default. It gives timely visibility without being unnecessarily aggressive for most services.
10 minutes	Lower-priority pages, internal-facing services, secondary endpoints, or less frequently used systems.	Use when awareness matters but immediate notification is less critical.

Practical recommendation Use 5-minute checks as the default for most monitors. Move to 1-minute checks for critical production paths such as checkout, login, public APIs, and high-value customer-facing services.

Global checks and verified downtime

Spark Uptime checks monitors from 11 global locations using the same monitor type and options you configure. This helps distinguish a real service issue from a temporary regional routing problem, single-location network issue, resolver issue, or isolated connection failure.

A monitor is treated as a verified down event after two down results. When downtime is verified, configured integrations and notifications can trigger. This confirmation step helps reduce false positives while still giving teams timely alerting when a real issue is detected.

Decision guide

I need to monitor a homepage or storeUse a Website monitor. This is the best default for most public sites.

I need to confirm specific text appearsUse a Keyword monitor with the exact case-sensitive keyword.

I need to check an IPv4 or IPv6 hostUse a Ping monitor when ICMP reachability is the signal you need.

I need to check SMTP, SSH, a database, or custom serviceUse a Port monitor and enter the TCP port number from 1 through 65535.

Best practices

Use Website monitoring as the default for public websites and customer-facing URLs.
Use Keyword monitoring when the correct page content matters, not only the response status.
Use Ping monitoring for network-layer reachability, not application health.
Use Port monitoring for specific TCP services, especially email, SSH, database listeners, and custom services.
Use 5-minute checks for most services and 1-minute checks for critical production paths.
Monitor the exact hostname, protocol, and URL your users rely on.
Pair Website monitoring with SSL/TLS monitoring so certificate issues do not surprise users.

Operational takeaway The right monitor type should match the user impact you care about. If customers load a page, use Website. If content must be present, use Keyword. If an IP must respond, use Ping. If a TCP service must accept connections, use Port.

Create Account Back to Monitors