Your monitoring tool knows your service is down. But is it down for everyone, or just from your server? Is it unreachable in South America, or just slow in Germany? Is your CDN routing traffic correctly after that DNS change, or is the old record still resolving in Asia? These questions are what separate uptime monitoring from uptime understanding.

Uptime Kuma answers the first question elegantly: is this endpoint up or down? It's self-hosted, MIT licensed, runs on a Raspberry Pi, and has the cleanest monitoring dashboard in the open source space. Globalping answers the second: run a check from anywhere in the world in seconds, using a community-hosted probe network spanning every continent.

They integrate natively. Together they give you self-hosted uptime monitoring with global visibility — no paid SaaS required.

Uptime Kuma

Uptime Kuma is a self-hosted monitoring tool created by Louis Lam that does one thing well: tell you when your services go down and alert you immediately. It supports monitoring HTTP/HTTPS domains, keywords on webpages, DNS records, Docker containers, and even databases such as MySQL and SQL.

The project has 67,000+ GitHub stars and is one of the most-starred self-hosted tools on GitHub. The current stable release is version 2.x. It's MIT licensed — genuinely open source with no commercial restrictions.

Monitor types

Uptime Kuma supports monitoring for HTTP(s), TCP, HTTP(s) Keyword, HTTP(s) JSON Query, WebSocket, Ping, DNS Record, Push, Steam Game Server, and Docker Containers. The breadth covers most real-world monitoring needs:

• HTTP/HTTPS — check that a URL returns a 200 and optionally contains a keyword or matches a JSON path
• TCP port — verify a port is open on any host (databases, mail servers, custom services)
• DNS — verify DNS records resolve correctly (critical after DNS changes)
• Docker container — monitor container health state directly from the Docker socket
• Push monitor — your application sends a heartbeat to Uptime Kuma; if it stops, you get an alert (perfect for cron jobs)
• Ping — ICMP ping with response time tracking

Check intervals go down to 20 seconds — faster than most SaaS monitors. Uptime Kuma's 20-second check interval is genuinely faster than many alternatives' 1-minute minimum. If sub-minute monitoring matters to you, that's a real advantage. Unlimited monitors, no per-monitor pricing.

Notifications

Notifications work via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services. If you want to send alerts to a niche notification service, Uptime Kuma probably supports it. Webhooks cover custom destinations — pipe alerts into n8n, Windmill, or any automation platform.

Status pages

Uptime Kuma generates public status pages showing the health of your services with uptime history. Useful for communicating service status to users and customers without giving them access to your dashboard. You can add your own domain, custom logo, and select which monitors to include per page.

Certificate expiry monitoring

TLS certificate expiry is tracked automatically on all HTTPS monitors. You get an alert before the certificate expires, with configurable advance warning. Given how many incidents are caused by forgotten certificate renewals, this alone justifies the deployment.

Self-hosting Uptime Kuma

Uptime Kuma is the simplest self-hosted tool to deploy on this entire blog. Single Docker command, SQLite database, no external dependencies:

docker run -d \
  --restart=unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:2

Or with Docker Compose:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./uptime-kuma-data:/app/data

Navigate to http://your-server:3001, create your admin account, add your first monitor. Done. Put Traefik in front for HTTPS and a clean domain. Minimum requirements: 512MB RAM, single CPU — runs comfortably on a Raspberry Pi.

Globalping

Globalping is a community-powered platform for running network measurements from anywhere in the world. Globalping is a platform that allows anyone to run networking commands such as ping, traceroute, dig, curl, and mtr on probes distributed all around the world.

The project is developed by the jsDelivr team — the same team that runs one of the world's largest CDN networks — and is fully open source. At peak, Globalping handles 2 million+ tests per day. The probe network spans hundreds of cities across every continent, including residential ISP networks (eyeball networks) that data-center-only monitoring can't replicate.

The core architecture: anyone can run a probe by spinning up a Docker container. That probe joins the global network and contributes its location to the pool. The probes will only issue an outgoing WebSocket connection to the Probe Management Module. There are no open ports on the probe, nor will it ever accept any incoming connections, limiting the risk of unauthorized access or attacks against the probe itself.

What Globalping can measure

• Ping — ICMP or TCP ping with RTT and packet loss from any location
• Traceroute — visualize routing paths across the world
• DNS lookup — verify DNS resolution from specific regions, ISPs, or cities
• HTTP — full HTTP request with response headers, TLS details, and timing
• MTR — combined ping and traceroute for detailed network path analysis

Location targeting

Location selection is Globalping's most powerful feature. You can be as broad or precise as you need:

• world — random probe anywhere
• Germany — random probe in Germany
• Germany+datacenter-network — German probe on stable datacenter infrastructure
• comcast+california — Comcast ISP probe in California (eyeball network)
• AS13335 — any probe on Cloudflare's ASN
• us-east-1 — cloud region targeting

This granularity is what makes Globalping genuinely useful for real-world debugging. "Is this DNS change propagated in Germany?" becomes a one-command answer.

CLI and free tier

# Install
npm install -g @globalping/cli

# Ping devopspack.com from Germany
globalping ping devopspack.com from Germany

# DNS check from multiple locations
globalping dns devopspack.com from world --limit 5

# HTTP check from Brazil
globalping http devopspack.com from Brazil --protocol HTTPS

Anonymous usage gets 250 free tests per hour with up to 50 probes per measurement — sufficient for most teams. Create a free account to increase limits. Running your own probe earns credits. Become a GitHub Sponsor for $10/month and get a hardware probe to install in your home or office network.

Uptime Kuma + Globalping — the native integration

This is where both tools become genuinely more valuable together. With a typical Uptime Kuma setup, you monitor from the location where the tool is running. Now that Globalping is integrated, Uptime Kuma can offer you more than single-location monitoring: you can monitor from anywhere.

Setting up a Globalping monitor in Uptime Kuma:

1. Add a new monitor in Uptime Kuma
2. Select "Globalping - Access global monitoring probes" from the Monitor Type dropdown
3. Configure the subtype: ping, dns, or http
4. Set the hostname: your domain or IP
5. Set the location: world, Germany+datacenter-network, Brazil, or any Globalping location string
6. Optionally add your Globalping API token under Settings → About to increase your free test limits

You can fine-tune probe selection and tell Globalping where you want to monitor from. You can provide locations such as continents, countries, cities, ASNs, networks, and network types.

Practical monitoring setups with the combination:

• Primary monitoring — local HTTP monitor every 60s for fast alerting on your local server

• Global availability — Globalping HTTP monitor from world every 5 minutes to confirm global reachability

• Region-specific — Globalping DNS monitors from EU, US, and Asia to verify DNS propagation after changes

• ISP coverage — Globalping ping from eyeball networks to verify end-user reachability, not just datacenter reachability

  Example: verify CDN is routing correctly post-deployment

  globalping http devopspack.com from EU --limit 10 --protocol HTTPS

  Check DNS propagation

  globalping dns devopspack.com from world --limit 20 --type A

The broader monitoring picture

Uptime Kuma and Globalping cover uptime and availability. They don't replace a full observability stack (Grafana + Prometheus for metrics, SigNoz for traces and logs). The right mental model:

• Uptime Kuma — is it up? Alert me when it's not. Status page for my users.
• Globalping — is it up everywhere? What does the routing look like from Japan?
• Grafana + Prometheus — how is it performing? Memory, CPU, request latency, error rates.
• SigNoz — why did that request fail? Trace it through the stack.

Each tool has a clear job. Uptime Kuma + Globalping handles the "is it reachable?" layer simply and for free.

Who it's for

Uptime Kuma:

• Any team running self-hosted services who wants to know immediately when something goes down
• Teams that need a public-facing status page without paying for Statuspage
• Anyone running cron jobs who wants heartbeat monitoring
• Solo developers who want UptimeRobot's functionality without the limitations and data leaving their server

Globalping:

• Teams debugging CDN, DNS, or routing issues and needing multi-location visibility
• Anyone who has ever asked "is it down just for me?" and wanted a real answer
• DevOps teams verifying DNS propagation after DNS changes
• Teams with global users who need to verify availability from specific regions or ISPs

My take

Uptime Kuma is the monitoring tool I recommend to every team that isn't already running one. The deployment is trivial, the interface is genuinely pleasant to use, the notification integrations cover everything, and the 20-second check interval beats most paid alternatives. It earns its 67,000+ stars. Just deploy it.

Globalping solves a problem that sounds simple but is surprisingly hard: how do you know your service is reachable from a residential connection in Brazil, or from a Comcast subscriber in California, without maintaining probes in those places? The community probe network is the answer, and the integration with Uptime Kuma means you get global monitoring without building anything beyond your existing self-hosted stack.

The combination gives you what teams typically pay hundreds of dollars a month for (Pingdom, Better Uptime, Checkly) for the cost of infrastructure and one Docker container. For any team running a self-hosted stack, this is the monitoring setup I'd start with.

---

PIPOLINE · DEVOPS CONSULTING

Need help setting up monitoring for your stack?

Deploying Uptime Kuma, configuring monitors across your self-hosted services, wiring Globalping for global coverage, setting up notification channels, and building a status page — takes an afternoon done properly. I can set up a complete monitoring layer for your infrastructure and connect it to your alerting workflow. You get visibility from day one.

Get in touch at pipoline.com →