Skip to content
<Rojit />
Uptime: 99.9%· 2025

Server Uptime Monitoring

Lightweight Go-based uptime monitoring tool with multi-site health checks, Slack alerts, and Prometheus metrics. Detects downtime before clients report it.

Technical case study by Rojit Pokharel — Full-Stack Web Developer & System Architect, Kathmandu, Nepal

GoPrometheusDockerREST APIYAML

Stack diagram

Application
GoREST APIYAML
Infrastructure
PrometheusDocker
Client / Problem
$
  • ›Agencies discover client-site downtime only after a client complains — too late, and reputational.
  • ›Existing monitoring SaaS is overkill, per-site priced, and adds external dependencies for simple uptime checks.
  • ›Teams need one lightweight tool that checks many sites, alerts on failure, and exposes metrics.
My Role
$
  • ›Open-source developer — built the tool in Go from scratch: config-driven multi-site health checks, Slack alerting, Prometheus metrics, and a REST API.
  • ›Authored the project documentation and deployment guide.
Architecture
$
  • ›Go binary configured via YAML declaring sites and check intervals.
  • ›Concurrent health checks with configurable HTTP methods, expected status codes, and timeouts.
  • ›Prometheus metric exposition endpoint plus a REST API for on-demand status queries.
  • ›Slack webhook alerts fired on state transitions (up→down, down→up) to avoid alert spam.
API Architecture
$
  • ›REST API exposing current status and check history for integration into dashboards.
Deployment
$
  • ›Distributed as a single static Go binary — runs anywhere with zero runtime dependencies.
  • ›Docker image provided so teams can drop it into an existing compose stack.
Performance Optimization
$
  • ›Go's concurrency model checks many sites in parallel with low resource footprint.
  • ›Prometheus metrics enable alerting and long-term trend analysis without a heavy backend.
Problems Encountered
$
  • ›Alert fatigue — naive per-failed-check alerts spam a Slack channel during an outage window.
  • ›Misconfigured checks (too-fast timeouts) produced false positives on slow-but-alive sites.
How I Solved Them
$
  • ›State-transition alerting fires only when status changes, with optional re-notify intervals.
  • ›Configurable timeouts and retry thresholds per site eliminate most false positives.
Results
$
  • ›Open-source uptime monitoring in Go with Slack alerts and Prometheus metrics — detecting downtime before clients do.
  • ›Used to monitor production client sites with 99.9%+ target uptime.
Lessons Learned
$
  • ›Alert on state changes, not on every failed check.
  • ›A single static binary is the lowest-friction way to get ops teams to adopt a monitoring tool.
Related Reading

Full-Stack

Real-World Impact: Production Projects That Deliver Results

A deep dive into six production projects that solve real business problems — from restaurant SaaS and insurance platforms to multi-container deployments and real-time systems.

Go

Server Monitoring Tool: Detect Website Downtime Before Your Clients Do

Deploy a lightweight open source server monitoring tool built in Go to detect website downtime before clients report it.

Answers

Read the Answers

Direct answers to questions about Rojit Pokharel and the technologies used across these projects.

Want a production system like this?

I build production web applications end-to-end. Let's discuss your project.

Get in Touch