alertping ▸ probe db-01.acme.net
no agent
icmp ping · 24 ms · reply
tcp :22 ssh · open · 29 ms
tcp :5432 postgres · open · 31 ms
tcp :25 smtp · banner 220 OK
tls :443 · chain valid · 161 days left
UP · FRA + IAD + SIN · next probe 30 s
server monitoring · outside-in
Server monitoring tool that checks from where your users are
A server monitoring tool does not need an agent to tell you a server is unreachable. AlertPing probes from the outside: ping, TCP and UDP ports and service responses, every 30 seconds from three regions, with alerts in under 10 seconds.
agentless by design
Why outside-in catches what agents miss
An agent reports from inside the box, over the very network path that may be broken. It can happily say “all good” while nobody on the internet can reach you. These four failure classes are invisible from the inside:
network
Routing and peering failures
A bad BGP route or a carrier outage drops traffic long before it reaches your server. The agent inside never notices. A probe from Frankfurt does.
dns
Expired or broken DNS
A lapsed domain or a botched record change takes you offline while every local metric stays green. Outside-in resolves the name the way a customer does.
firewall
Firewall rule regressions
One tightened security-group rule blocks port 443 to the world. The service runs, the agent reports it running, and no request gets in. A port monitoring check fails within 30 seconds.
tls
Certificate expiry and chain breaks
Browsers reject an expired or mis-chained certificate; the process serving it has no idea. External checks validate the full chain and warn 30, 14, 7 and 1 day out.
zero install
Works with any stack, because it touches none of it
There is no agent to install, no package to keep patched, no config file to drift out of sync across 30 boxes. If a host answers ping monitoring probes or speaks TCP on a port, AlertPing can watch it: bare metal in a rack, a $4 VPS, a Kubernetes ingress, a Windows box running IIS.
Jobs behind the firewall are covered too: cron job monitoring flips the direction, your job pings us when it runs and we page you when it goes silent. When something is confirmed down, downtime alerts go out by SMS, email, Slack and webhook, with escalation chains on Team and up.
honest note · what we do not do
No CPU, RAM or disk graphs. On purpose.
AlertPing is not an APM and does not pretend to be one. We do not read your load average or your memory pressure. We watch the one thing those metrics are a proxy for: whether your users can actually reach the service, right now, from three places on the internet.
Plenty of teams run AlertPing next to an internal metrics stack. The internal tools explain why something broke. We are the ones who tell you it broke, first.
▸ we measure what users experience
check types
Three layers of proof that a server is really up
Stack them per host. A failure at any layer triggers instant re-probes from the other two regions; 3 of 3 must agree before anyone is paged.
-
1
Reachability: ICMP ping
Is the host answering at all? Latency and packet loss from Frankfurt, Virginia and Singapore, every 30 seconds.
-
2
Ports: TCP and UDP
Is the port open and accepting connections? SSH, SMTP, databases on exposed ports, game servers, anything custom.
-
3
Service: real responses
Is the service answering correctly? HTTP status and keywords, SMTP banners, TLS chain validity. Open ports with broken services do not fool it.
Watch your servers the way your users reach them
Ping, port and service checks every 30 seconds from 3 regions. No agent, no config drift, alerts in under 10 seconds.