Failed check
Fastest · more noise
Is your server actually reachable on the port?
A live host doesn't mean a working service. Spectra connects to the exact ports your databases, caches, and mail servers listen on — and confirms each one is open before you hear about it from a customer.
One tap to fill in the port. Every common service pre-loaded.
Pick a preset or enter any custom port — Spectra knows the services your stack runs on.
5432
PostgreSQL
3306
MySQL / MariaDB
6379
Redis
27017
MongoDB
25
SMTP
443
HTTPS
22
SSH
21
FTP
9200
Elasticsearch
5672
RabbitMQ
1433
SQL Server
11211
Memcached
We confirm DOWN from 2+ regions before alerting.
Port checks run simultaneously from multiple geographic locations. A single regional failure won't page your team — we need 2+ regions to agree before an alert fires.
-
Free plan — 1 fixed region
Free plan monitors check from a single fixed region — a simple up/down signal to get you started.
-
Essential — choose any 2 regions
Pick any 2 from the global list; both must confirm failure before any alert fires, so a regional blip never pages you.
-
Pro — choose any 5 · Pro+ — 10+ regions
Maximum global coverage. Monitor from many locations simultaneously. Avg latency, min, max, and packet loss tracked per region on every check.
-
Firewall tip — allow list our probe IPs
If your service sits behind a firewall, use the built-in connection test to see which regions are blocked. Then allow list Spectra's probe node IP ranges per region.
Every port failure becomes an incident — automatically.
When a port goes DOWN, Spectra auto-creates an incident with a full timeline. Post status updates to your public page and track every second of downtime.
- 1
Port refused connection — DOWN confirmed
Mumbai & Singapore both report connection refused on TCP :5432. Incident auto-created.
- 2
Team notified
Email sent to [email protected]. Slack alert posted to #infra-alerts. Status page updated to "Investigating".
- 3
Port accepting connections — RECOVERED
All regions reporting port open. Connect time 12ms. Downtime duration 17m 13s. Recovery alert sent.
When a port goes down — your customers can see it too.
Every port failure auto-creates an incident. Add your port monitor to a public status page so your team and customers both know what's happening — before the support tickets arrive.
Require consecutive failures before alerting.
A momentary packet loss or brief network blip shouldn't page your on-call team. Require multiple consecutive failures before marking DOWN — and multiple successes before marking recovered.
Confirm DOWN after:
Confirm RECOVERY after:
Consecutive failures
Default · recommended
Consecutive failures
Most conservative
Successful check
Default · recommended
Consecutive successes
Avoids flapping
Consecutive successes
Most stable
App default: Confirm DOWN after 2 consecutive failures · Confirm RECOVERY after 1 successful check. Require multiple consecutive failures before marking DOWN — reduces false positives from momentary packet loss.
Frequently Asked Questions
Answers to common questions teams ask us
What is port monitoring?
It checks whether a specific TCP/UDP port on your host accepts connections — confirming the service behind it (database, mail, SSH, cache) is actually listening, not just that the host is alive.
Which ports can I monitor?
Any port. Pick from common presets like SSH, HTTP(S), MySQL, PostgreSQL, Redis, and SMTP, or enter any custom port number your service uses.
How do you avoid false alarms?
Spectra confirms a failure from two or more regions and requires consecutive failures before opening an incident, so a single dropped connection won't page you.
Can I monitor internal services?
Yes — with private location agents you can watch ports on hosts that aren't exposed to the public internet.
What's the difference between port and ping monitoring?
Ping confirms the host answers on the network; port monitoring confirms a particular service on that host is accepting connections. Together they pinpoint exactly where a failure is.
