Internal monitoring

Monitor servers behind a firewall, and get paged from outside it.

Short answer: yes. Install the open-source pylon-beacon agent on one machine inside the network. It pushes outward over HTTPS every 20 seconds — no inbound port, no VPN, no tunnel — and it can probe any internal target you name (an intranet site, a NAS share, a print server, a hypervisor UI, a game server port). Each probe becomes its own monitor in PylonMon with real latency, history and alerts, and if the whole site loses power or internet, the agent’s silence is itself the page. Free for three machines; no card.

Why a normal uptime monitor can’t do this

An uptime service checks from the public internet, which is the point: it sees what your users see, and it keeps working when your building doesn’t. But 192.168.1.50, 10.0.0.9 and intranet.local don’t exist out there. Pointing an external monitor at them fails by construction, and opening those services to the internet so a monitor can reach them is exactly the wrong trade. You need something inside that reports out.

How it works

your network (no inbound ports opened) the internet ┌──────────────────────────────────────────────┐ │ intranet ──┐ │ │ NAS (445) ──┤ probes, every 20 s │ HTTPS push, outbound only │ printer ──┼──► pylon-beacon ────────────┼──────────────────────────────► PylonMon │ hypervisor──┤ (one static binary, │ │ │ game host ──┘ on any Linux/Windows box) │ alerts: ▼ └──────────────────────────────────────────────┘ email · SMS · Discord · Slack webhooks · voice · push agent silent for 1.5 × interval ═══► "site is dark" page, one alert, not one per target

One agent, many targets. The agent’s [probes] section lists what to check: http (any response below 500 counts as up, self-signed certificates accepted), tcp (a connect), ping. Up to 20 per agent, all run concurrently, never delaying the agent’s own check-in.
Node vitals ride along. CPU, memory, disk per mount, load, temperature, uptime and network throughput from the machine running the agent, with threshold rules on any of them.
Silence is the signal. If the agent misses its window (1.5× the push interval, minimum 30 s), the node pages once and its probes go stale rather than paging twenty times. A single missed probe sample never pages; two in a row do.
Outside and inside together. Keep normal external monitors on anything public (your website, mail, VPN endpoint) and let the beacon cover what’s private. Dependencies group them: if the router is down, the twenty things behind it don’t each page you.

A worked example: a school district

An in-house IT lead runs a district network: a web server in the DMZ, an internal intranet, two file servers, a print server, a hypervisor, and — on the side — a Minecraft host for a club. Nothing internal is reachable from outside, and it must stay that way.

What	How it’s monitored	Who gets paged
Public website and mail	External HTTP and TCP monitors from PylonMon’s two regions	IT lead by email and SMS
Intranet (internal only)	`intranet = http https://intranet.district.local` on the web server’s agent	IT lead
File servers, print server	An agent on each: vitals (disk!), plus `smb = tcp 10.0.0.20:445`	IT lead; disk rules page at 90 %
Hypervisor	Agent on the host: vitals; `ui = http https://10.0.0.5:8006`	IT lead
Game host (6 ports, a database, a cache)	One agent, eight `tcp` probes; nightly restarts in a maintenance window	The club’s Discord, not the IT lead’s phone
A client’s view	A public status page showing only their monitors	—

That is 19 nodes and about 40 monitors. On the Pro plan ($9/month: 75 monitors, one status page, 10 SMS a month, 30-second checks) it fits with room to grow; a second client status page is +2 for $5, or Team ($49) brings three pages, five members and on-call rotations.

Setting it up

1 · INSTALL

One command, inside

Linux: curl -fsSL https://pylonmon.com/beacon.sh | sh — Windows: irm https://pylonmon.com/beacon.ps1 | iex. It asks for an ingest-scoped API key (free, can’t read anything) and registers as a service.

2 · NAME THE TARGETS

A few lines of config

[probes]
intranet = http https://intranet.district.local
nas = tcp 10.0.0.20:445
core = ping 10.0.0.1
Restart the agent; each line appears as a monitor under the node within a minute.

3 · ROUTE THE ALERTS

Set channels once

Probes inherit the node’s channels. Put the school on email + SMS and the game host on Discord, add a maintenance window for anything that restarts on a schedule, and link dependencies so one root cause pages once.

Limits and honest caveats

Probe kinds are http, tcp and ping. SNMP devices (switches, UPSes, printers) are read through the agent’s [snmp] section instead; UDP services are checked by the external UDP monitor where they’re reachable.
Up to 20 probes per agent; run more agents for more. Every probe and every node counts as one monitor against the plan cap (Free 20, Pro 75, Team 250).
The agent needs outbound HTTPS to pylonmon.com. If your egress is filtered, allow that one destination; nothing inbound is ever required.
A probe measures reachability and latency from the agent’s position — it does not log in, run queries or read application health beyond the HTTP status.
The Free plan includes 3 nodes; paid plans raise nodes to the monitor cap.

And for the parts the internet can see

Everything public stays on ordinary external monitors, checked from the public internet (HTTP, TCP and DNS failures are confirmed from a second region before paging on paid plans), and TLS certificates get expiry and chain validation (the free chain checker shows what that looks like). Our checks come from a published set of addresses, so a firewall can allow them for services that are semi-public.

Start free — 3 nodes, 20 monitors, no card Agent source: github.com/PylonMon/pylon-beacon