Most hosted monitoring can only see what you expose to the internet. Pingura’s private probes run inside your network — no public IP, no inbound firewall rule.
Conventional uptime tools check your services by connecting to them from the outside. That works for a marketing site or a public API. It does not work for the database on a private subnet, the internal admin panel, or the staging environment behind your VPN — because there is nothing for an external checker to connect to.
The usual workarounds are all bad. Exposing an internal service to the internet just so it can be monitored adds attack surface for no functional benefit. Punching a firewall hole for a vendor’s IP range is fragile and hard to get past a security review. Self-hosting a monitor solves reachability but creates a worse problem: when the infrastructure fails, the thing that was supposed to tell you fails with it.
Private probes invert the direction of the connection. The agent runs inside your network and reaches out to Pingura, so checks happen locally while alerting stays hosted somewhere your outage cannot take down.
Run the lightweight Pingura agent on any machine inside the network you want to monitor. It needs outbound access to Pingura and nothing more.
Point monitors at internal hostnames or IPs and choose which probe should run them. The probe resolves and checks them locally.
Results flow into the same dashboard, alerting, history, and status pages as your public monitors. Nothing about the workflow changes.
Services deliberately kept off the public internet still need monitoring. A probe checks them from inside, where they are reachable.
MySQL, PostgreSQL, MSSQL, Redis, and Memcached checks run against hosts that no external service could ever connect to.
Where compliance forbids inbound access, an outbound-only agent is often the only monitoring approach that will pass review.
File servers, print servers, and local network gear that never had monitoring because it was not worth standing up a whole stack for.
Catch breakage in pre-production without exposing staging to the internet just so a monitoring service can reach it.
Older applications that were never designed to face the internet, and should not start now.
Private probes start on the Starter plan with one probe. Professional includes 5, Business includes 25 — alongside everything else: SSL and domain monitoring, heartbeats, server metrics, status pages, and incident management.
Yes. A private probe is a lightweight agent you install inside your own network. It runs the checks locally and reports results outward to Pingura, so the target server never needs a public IP, an open inbound port, or a firewall exception.
No. The probe makes outbound connections to Pingura. There is no inbound path from the internet to your network, which is precisely why this works where a conventional hosted monitoring service does not.
Anything the probe itself can reach on your network — internal APIs and admin panels, MySQL, PostgreSQL, MSSQL, Redis, and Memcached instances, SMTP, POP3 and IMAP servers, SSH, and plain TCP or ping checks against internal hosts.
Private probes start on the Starter plan, which includes one probe at $9/month. Professional includes 5 probes and Business includes 25.
A self-hosted monitor lives or dies with the infrastructure it is monitoring — if the rack loses power, so does your alerting. With Pingura the probe runs inside your network but the alerting, history, dashboards, and status pages are hosted externally, so an internal outage still reaches you.
Yes, and most teams do. Public endpoints are checked from Pingura’s five global regions while internal services are checked by your probes. Everything appears in the same dashboard, with the same alerting and the same status pages.
Start free, then add a private probe on Starter for $9/month.
Get Started Free