Monitoring
Quick answer
Monitoring in Portal checks whether the IP addresses you own are still answering. You set the checks up yourself under Networking & Security → Monitoring with Add Monitor, and choose between Ping (ICMP), TCP Port, HTTP(s) and HTTP(s) Keyword. Failing checks appear as Active Incidents. Your firewall has to let the check in, otherwise it fails while the service itself is healthy.
Monitoring is a check you configure yourself. Portal tests the address you give it, on the check type you pick, and flags it when the test stops succeeding. The page stays empty until you add your first check.
What you can monitor
You point a monitor at an IP address you own. There are four check types.
| Check type | What it tests |
|---|---|
| Ping (ICMP) | The address answers ICMP echo requests. |
| TCP Port | A TCP connection can be opened on the port you configure. |
| HTTP(s) | An HTTP or HTTPS request to the target gets a response. |
| HTTP(s) Keyword | The same request as HTTP(s), plus the response has to contain the keyword you set. |
Pick the check type that matches what you actually care about. Ping tells you the machine is reachable. TCP Port tells you a service is accepting connections. HTTP(s) tells you the web server answers. HTTP(s) Keyword tells you the page still contains what it should, which catches an application that returns a page but has lost its database.
Add a monitor
Open Monitoring
In Portal, go to Networking & Security → Monitoring. With nothing configured yet you see "No monitors yet" and the invitation to add a monitoring check to start tracking the availability of your IPs.
Select Add Monitor
Choose the check type and fill in what it needs: the address for every type, the port for a TCP Port check, and the keyword for an HTTP(s) Keyword check.
Check the list
Each monitor shows its type, its port, its current status and its uptime over the last 24 hours.
Work through Active Incidents
A failing check is listed under Active Incidents. Use Acknowledge once you have picked the incident up, so the rest of your team can see it is being handled.
Monitoring
Networking & Security → Monitoring
| Type | Port | Status | 24h uptime |
|---|---|---|---|
| Ping (ICMP) | n/a | Up | 100% |
| TCP Port | 443 | Up | 100% |
| HTTP(s) Keyword | 443 | Down | 97% |
Add Monitor
Monitors can also be managed through the Monitoring family of the Worldstream API, if you would rather define them alongside the rest of your infrastructure. See Using the Worldstream API.
What to allow through your firewall
A check only works if the traffic it needs can actually reach the target. Allow the following inbound, on the firewall in front of the address you are monitoring.
| Check type | Allow inbound to the monitored address |
|---|---|
| Ping (ICMP) | ICMP |
| TCP Port | TCP on the port you configured |
| HTTP(s) | HTTP or HTTPS to the target |
| HTTP(s) Keyword | HTTP or HTTPS to the target, and the page has to contain the keyword |
A blocked check looks like an outage: If your firewall blocks the traffic the check needs, the check fails even when the service is perfectly healthy. Check your rules before you treat a failing monitor as a real outage. That means both the firewall inside your operating system (UFW, iptables, firewalld, Windows Firewall) and any Portal firewall in front of the address.
If you need an allowlist
Worldstream does not publish fixed source IP ranges for the monitoring checks, so there is no list you can look up and paste into a rule. If your policy only allows traffic from named sources, open a support ticket and ask for the current source addresses. Do not derive them from your own logs, because what you see there is a snapshot and can change.
See Creating a support ticket and choosing a priority, or mail support@worldstream.com.
Monitoring is not security validation
Portal has a second feature that also watches your IP addresses, and it does something else. Continuous Security Validation, under Security in the sidebar, scans your public IPv4 addresses from the outside for CVEs, misconfigurations and exposed services. Monitoring answers "is it still answering?". Continuous Security Validation answers "what is it exposing?". You configure them separately and neither replaces the other. See Continuous Security Validation.
Next step: open Networking & Security → Monitoring in Portal and add one check for the address that would hurt most if it went down. If that check fails while the service is up, look at your firewall rules first, then raise a ticket for the source addresses.