Uptime Medics Architecture & Performance Benchmark: High-Performance Rust Uptime Monitoring
- Uptime Medics is a single-binary Rust service (< 30 MB RAM) built on Axum 0.8, Tokio 1, SQLite WAL, and Reqwest 0.12.
- Delivers zero-signup public community pools with 10-second juggler rotation, eliminating account friction.
- Implements multi-layer SSRF defense (DNS resolver filtering, rebinding detection, redirect hop inspection) to harden public monitoring forms.
- Features a 2-failure incident state machine, flapping suppression, and batched SQLite writes for reliability.
- Supports multi-method HTTP probing (HEAD, GET, POST, PATCH, PUT, DELETE, OPTIONS) with up to 64 KB payloads and custom headers.
Uptime Medics redefines uptime monitoring by combining ultra-lean performance with hardened security. This article dissects its architectural design, data flows, and real-world performance benchmarks.
The Engineering Challenge: Why Uptime Medics – High-Performance Uptime & Incident Monitoring Was Architected
Traditional monitoring solutions either cripple developers with enterprise-grade pricing or consume excessive resources on self-hosted stacks. Worse, public monitoring forms present severe SSRF risks, enabling attackers to probe internal networks, cloud metadata endpoints, or perform DNS rebinding attacks. Uptime Medics solves these pain points with a purpose-built Rust platform delivering sub-30 MB memory footprint, zero-signup community pools, and defense-in-depth SSRF protection.
Core Architecture & Technical Stack Deep-Dive
Single-Binary Design & Core Components
The service is packaged as a single binary, leveraging Rust 1.82 with Axum 0.8 (async web API), Tokio 1 (scheduler), Reqwest 0.1 (outbound HTTP), SQLx 0.8 (SQLite WAL), and Lettre 0.11 (SMTP). An embedded static frontend (rust-embed) is served directly from memory, eliminating file-system dependencies.
System Topology
Below is a simplified diagram of the runtime topology:
┌────────────────────────────────────────┐
│ User Web Browser │
│ (Vanilla ES Modules / HTML) │
└───────────────────┬────────────────────┘
│ Port 8080 (HTTP)
┌────────────────────────────────────────┐
│ Uptime Medics Single Binary │
│ (Axum 0.8 + Tokio) │
│ │
│ ┌─────────────────┐ ┌──────────────┐ │
│ │ Embedded Static│ │ Axum HTTP │ │
│ │ (rust-embed) │ │ API Router │ │
│ └────────┬────────┘ └───────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ AppState Composition Root │
│ (Database Pool, Mailer, Scheduler) │
└─────────────────┬───────────────────┘
│
▼
┌────────────────────────┐
│ SQLite Database (WAL) │
│ (Incident & Check log)│
└────────────────────────┘
Database & Caching Layers
SQLite in WAL mode ensures high-concurrency writes and crash-resilience. All check results and incident state transitions are batched via Tokio channels, reducing disk I/O. No external cache layer is required due to the sub-30 MB footprint and fast in-process scheduling.
Key Features Breakdown & Practical Benefits
Zero-Signup Community Monitoring
Anyone can submit a public monitor instantly. The landing page dynamically jugglers 10 random community monitors every 10 seconds, providing live global health telemetry without registration overhead.
Multi-Method HTTP Probing
Supports HEAD, GET, POST, PATCH, PUT, DELETE, OPTIONS with custom JSON/form headers and payload bodies up/overview 64 KB. Intervals range 30 s-1 hour, timeouts 1-6 seconds.
Defense-in-Depth SSRF Protection
- DNS Resolver Filtering blocks internal TLDs.
- DNS Rebinding Detection monitors IP changes over short windows.
- Redirect Hop Inspection validates each redirect target against allow-lists.
Incident State Machine & Flapping Suppression
A 2-failure incident model with batched SQLite writes ensures reliability. Flapping suppression prevents alert spam by requiring two consecutive failures within a defined window before triggering notifications.
Authentication & Authorization
Private dashboards are secured using Argon2id password hashing and JWT tokens, offering enterprise-grade credential protection.
Real-World Deployment & Production Topology
Uptime Medics can be deployed as a Docker container or directly on edge servers. The scheduler runs as a Tokio task, managing thousands of concurrent checks with minimal overhead. Monitoring data is stored locally (SQLite) or replicated externally via export hooks.
Data Flow & How It Works: Step-by-Step Workflow
1. Monitor Submission – Public monitors are ingested via POST /api/monitors; validation includes URL schema, method, headers, and payload size.
2. SSRF Sanitization – Incoming URLs undergo DNS filtering, rebinding checks, and redirect hop verification before enqueuing.
3. Scheduler Engine – Tokio interval tasks pull jobs from a priority queue, execute HTTP requests via Reqwest with configurable timeouts, and record results in SQLite.
4. State Transition – Results update the incident state machine; two consecutive failures trigger a notification email via Lettre.
5. Frontend Rendering – The embedded HTML/JS reads live metrics from /api/status and juggles community monitors in real-time.
Architectural Comparison: Uptime Medics – High-Performance Uptime & Incident Monitoring vs Traditional Approaches
| Aspect | Uptime Medics | Enterprise APM (e.g., Datadog) | Open-Source (e.g., Uptime Kuma) |
|---|---|---|---|
| Memory Footprint | <30 MB | >500 MB | 300-800 MB |
| Signup Requirement | Zero-signup for public pools | Mandatory account | Optional account |
| SSRF Protection | Multi-layer filtering | Limited | None |
| Probing Methods | HEAD/GET/POST/PATCH/PUT/DELETE/OPTIONS | GET/POST only | GET/POST only |
| Incident Logic | 2-failure state machine | Custom thresholds | Basic up/down |
Frequently Asked Questions (FAQ)
What programming language and framework powers Uptime Medics?
Leave a Reply