How to Set Up a Website Downtime Checker for Services Behind a Firewall
Most website downtime checkers probe your services from data centers on the public internet. That works for a marketing site, but it breaks the moment a service lives behind a firewall, on a private VLAN, or inside a Kubernetes cluster with no external IP: the probe never arrives, and the checker either reports a false outage or can't monitor the target at all.
The fix isn't a firewall change — it's moving the checker. This guide explains how a lightweight local agent closes that visibility gap, and how to set up your first internal check with DownWarning.
Why cloud-based checkers go blind on private services
A service on a private IP, inside a VPC with no internet-facing endpoint, or exposed only as a Kubernetes ClusterIP has no route back to an external probe. Every internal API, database, and service-to-service endpoint becomes a blind spot — and that blind spot grows with your infrastructure.
The usual workaround — opening an inbound port, assigning a public IP, or adding a reverse proxy just for monitoring — trades a visibility problem for a security one. An internal service is internal for a reason. The monitoring architecture should adapt to your network design, not the other way around.
How an outbound-only agent changes the equation
An agent-based checker inverts the connection. A small binary runs inside your network, checks internal targets locally, and sends the results to DownWarning over a standard outbound HTTPS connection. No inbound ports, no firewall rules to modify, no public IP — to the firewall, it looks like any other outbound HTTPS request.
The DownWarning agent runs on Linux, macOS, and Windows (including as a Windows service), or as a pod inside a Kubernetes cluster. It authenticates with an agent API key from the dashboard, picks up the monitors assigned to it, and updates itself when a new version ships. If the agent stops reporting, the dashboard flags it as offline, so a silent agent is never mistaken for healthy services.
What the agent can check
A downtime checker has one focused job: probe a target on an interval, verify it responds correctly, and alert when it doesn't. For internal targets, the agent supports three check types:
HTTP(S)
Full request-response checks against internal APIs and web apps: HTTP method, custom headers, authentication, expected status codes, and a keyword that must (or must not) appear in the response body.
Ping
ICMP reachability for hosts and network devices. Useful for infrastructure, but a successful ping doesn't prove the application is working — pair it with an HTTP or Port check.
Port
TCP connectivity for non-HTTP services such as databases, Redis, message brokers, and SSH, where "is the port accepting connections?" is the right question.
DNS checks and SSL certificate expiry tracking run from DownWarning's external probes, so they apply to publicly reachable endpoints, not to agent-assigned monitors. If a service has both a public and an internal endpoint, monitor the public one externally for DNS and SSL, and the internal one through the agent.
Setting up your first internal check
1. Install the agent
Create an agent in the DownWarning dashboard to get its API key, then run the binary on a machine (or as a pod) inside the private network, passing the key with --api-key, the MONITOR_API_KEY environment variable, or a config.yaml file. One agent can usually cover a whole network segment.
2. Create a monitor for the agent
Choose HTTP, Ping, or Port, enter the internal target — a private IP, an internal hostname, or a cluster address like orders.default.svc.cluster.local — and assign the monitor to your agent instead of the external probes. Agent monitors run at intervals of 60 seconds or more.
3. Connect alerts and verify
Attach one or more alert contacts to the monitor, then watch the first results in the dashboard. An error on the first run usually points to DNS or routing between the agent and the target; the failure reason in the check result tells you which layer failed.
On Kubernetes clusters that enforce NetworkPolicies, add a scoped policy that lets the agent's namespace reach the application namespaces on the ports you monitor. Keep it least-privilege and test it outside production first.
Wiring in alerts people act on
An alert that lands in the wrong place is effectively no alert. DownWarning notifies through email, Slack, Microsoft Teams, Telegram, Discord, Google Chat, and webhooks — which you can route into PagerDuty, Opsgenie, or your own automation. Assign different contacts per monitor, so the database alert reaches the DBA team and the internal API alert reaches its owners.
Each alert includes the monitor name, the failure reason, and a link to the incident, and a recovery notification goes out through the same channels when the service comes back. Alerts fire on the first failed check, so choose the interval by how quickly you need to know: one minute for critical internal services, longer for everything else.
Put the checker where your services live
A downtime checker only works if it can reach the service. For anything behind a firewall, the external probe model breaks by design, and exposing services to make the checker happy is the wrong fix. An outbound-only agent gives you HTTP, Ping, and Port coverage of private and Kubernetes services without touching a single inbound rule.
Frequently Asked Questions
Can a cloud-based downtime checker monitor services behind a firewall?
Not without exposing them. External probes need a route to the target, so private IPs, VPC-only services, and Kubernetes ClusterIP services look permanently down. A local agent inside the network avoids that by checking locally and reporting outbound.
Do I need to open any inbound firewall ports for the agent?
No. The agent only makes outbound HTTPS connections to DownWarning. Your inbound firewall rules stay exactly as they are.
Which check types work through the agent?
HTTP(S), Ping, and Port checks. DNS checks and SSL certificate expiry tracking run from DownWarning's external probes against publicly reachable endpoints.
Is the local agent available on the free plan?
Yes. The free Starter plan includes one local agent, so you can monitor a private network or Kubernetes cluster at no cost. Upgrade to Pro or Scale when you need more agents to cover additional networks.