Monitor services
behind your firewall
Run a single Lighthouse agent inside your private network and watch internal HTTP, TCP, UDP and SSL services from where they actually live. No inbound ports, no VPN, no firewall changes — the agent opens an outbound HTTPS connection back to Status Harbor and reports its own results.
What is a Lighthouse?
A Lighthouse is a small, static binary that runs anywhere you can run a Linux process — a VPC, a Kubernetes cluster, or a bare-metal server in a datacenter. It receives its check configuration from Status Harbor over outbound HTTPS, runs the checks against services on its own network, and streams state transitions back to your dashboard.
Because the agent only ever makes outbound HTTPS calls, you do not need to open inbound ports, set up a reverse tunnel or expose anything to the public internet. The same firewall rules that already let your services call out to the open web are enough for the agent to talk to Status Harbor.
Pair it with the cloud probes from our 9 public regions and one dashboard covers public-facing sites and the private services behind them.
What a Lighthouse can probe
These check types cover almost everything you ship behind a private network.
| Protocol | Typical use | What we check |
|---|---|---|
| HTTP / HTTPS | Internal admin panels, private APIs, health endpoints behind a VPN or VPC | Status code, response body match, headers |
| TCP | Internal databases, message brokers, cache nodes, custom socket services | Connect success, handshake validity |
| UDP | Internal DNS resolvers, game servers, VoIP, custom UDP services | Packet send / response |
| SSL | TLS certificates on internal Ingresses, admin panels and mTLS endpoints | Days to expiry, expired or unreachable cert |
| DNS | Internal resolvers and in-cluster CoreDNS records | Record value match, drift detection |
Set up a Lighthouse in under five minutes
From mint-token to first check, no firewall changes required.
- 1
Create a Lighthouse
In Status Harbor, click + New Lighthouse, give it a name and copy the install command. The token is shown only once — store it the way you would any other secret.
- 2
Run the agent on a host inside your network
Paste the one-line install command on any Linux host that can already reach the services you want to monitor and the open internet. The agent runs as a single static binary — no runtime, no package manager, no dependencies.
- 3
Attach checks (or adopt the ones we discovered)
From the Status Harbor dashboard, point HTTP, TCP or UDP checks at the Lighthouse instead of a cloud region. On Kubernetes, the agent also surfaces every Ingress and externally-facing Service it sees as a one-click Discovery — adopt the ones you want to monitor, hide the rest. The agent picks new and adopted checks up on its next heartbeat — usually within seconds.
- 4
Get alerts where you already do
Failures from private checks alert through the same Slack, Telegram, email or webhook channels as your public monitors. One on-call surface for everything.
Auto-discovery on Kubernetes
On Kubernetes, the Helm install is the whole config. The agent watches Ingress and externally-facing Service resources in the namespaces you configure (every namespace by default) and surfaces them in your dashboard as one-click suggestions.
- Ingresses — every host+path the agent sees becomes an HTTP or HTTPS suggestion (scheme inferred from the Ingress's TLS block; you can override at adopt time).
- Services — LoadBalancer and NodePort services fan out one suggestion per port. Port name
http/httpsor numbers 80/443 classify as HTTP/HTTPS; everything else becomes TCP, UDP if the port is UDP. ClusterIP and headless services are skipped. - Hide what you don't want. The dashboard filters out hidden suggestions; nothing is monitored until you click Adopt.
- No surprises on billing. Discovered endpoints don't count against your monitor limit. Only adopted ones do.
Discovery is on by default for Helm installs. Disable with --set discovery.enabled=false, or scope to specific namespaces with --set 'discovery.namespaces={prod,staging}' (which downgrades the agent's RBAC from a ClusterRole to per-namespace Roles).
Designed for networks you don't want to open
- Outbound HTTPS only. The agent talks to Status Harbor on a single TLS connection it initiates. No listener, no inbound rule, no port-forward.
- Per-agent bearer token. Each Lighthouse gets its own token, scoped to that one agent and revocable from the dashboard. Lose a host, rotate the token, the old one is dead the moment you click revoke.
- Static binary, small surface. No runtime, no plugins, no auto-update. The binary you install is the binary that runs until you replace it.
- Only check metadata leaves your network. Status, latency, status code and the error string your service returns — nothing else. The agent does not exfiltrate response bodies, payloads or anything you didn't ask it to probe. See the Privacy Policy for the exact field-by-field list.
Common questions
Why do I need an agent for private network monitoring?
Cloud-based uptime checks come from public IP addresses. If the service you want to monitor is on a private subnet, behind a corporate VPN or only reachable from a Kubernetes cluster's internal DNS, no public probe can reach it. An agent solves this by running on a host that already lives on the right network — it can resolve the internal hostname and reach the internal port — and reports its results back over an outbound HTTPS connection that any standard egress policy already allows.
Where can I run the Lighthouse agent?
Anywhere you can run a Linux process. Common deployments include a small VM inside an AWS / GCP / Azure VPC, a pod in a Kubernetes cluster, or a bare-metal server in a colocation rack. The only requirement is outbound HTTPS to Status Harbor and reachability to whatever services you point it at.
Do I need to open ports or set up a VPN?
No. The agent only makes outbound HTTPS calls. There is no inbound listener, no port to expose and no tunnel to manage. If your network already lets the host reach the open internet on port 443, you have everything you need.
What happens if the agent loses connectivity?
The agent keeps running its local checks and buffers state transitions in memory. When the connection comes back, it ships the buffered events in order. If the agent stops sending heartbeats for longer than a short threshold, Status Harbor flags the Lighthouse itself as offline so you don't mistake "agent is dead" for "everything is healthy."
What data does the agent send back?
Per check, the agent reports: the new state ("up" or "down"), the previous state, response time in milliseconds, status code (for HTTP), the error string returned by the probe and a timestamp. Per agent, it also reports its version, hostname and a periodic heartbeat. Response bodies, request payloads and anything beyond the keyword or header rules you explicitly configured stay on your network. The full list is in the Privacy Policy.
How many Lighthouses can I run?
Lighthouses are available on paid plans, with a per-plan cap. Most teams run one per network — one in a production VPC, one in a staging VPC and a third in an on-prem datacenter is a typical shape. Check the pricing page for the exact cap on your plan.
Watch your private services in minutes
One static binary, an outbound HTTPS connection, and the same alerting you already use.
Start freeRelated
- Kubernetes monitoring for clusters, Ingresses and Services — drop the agent into a cluster and auto-discover endpoints.
- On-prem and private cloud monitoring — watch datacenter systems cloud-only tools can't reach.
- SSL certificate monitoring — catch expiry on certificates behind the firewall.