Uptime Medics: High-Performance Rust Uptime Monitoring Architecture & Benchmarks
Key Takeaways
- 30MB single-binary Rust architecture with sub-millisecond probe dispatch via Tokio async scheduler
- Enterprise-grade SSRF protection with custom DNS resolver blocking 16+ forbidden network ranges
- Zero-signup public monitoring pools with 10-second random juggler for community transparency
- Two-failure incident state machine and intelligent flapping suppression prevent alert fatigue
- Transactional SQLite WAL mode with batched writes maintains performance under load
The Challenge: Why Uptime Medics Was Built
Modern uptime monitoring solutions face four critical challenges that Uptime Medics addresses through its Rust-based architecture:
- Resource Bloat: Node.js monitors consume 300-800MB RAM vs 30MB for this Rust binary
- SSRF Vulnerabilities: Traditional tools lack protection against internal network probing via DNS rebinding
- Alert Fatigue: Single failure triggers and flapping services bombard teams with false positives
- Friction: Commercial solutions impose paywalls and mandatory signups for basic monitoring
Core Architecture & Technical Stack Deep-Dive
Layered Rust Modules
src/
├── Presentation Layer (api/)
│ ├── router.rs - Axum 0.8 HTTP routing
│ └── assets.rs - Embedded HTML/JS via rust-embed
├── Application Services (services/)
│ ├── scheduler.rs - Tokio 1.0 probe loop
│ └── probe.rs - Reqwest 0.12 HTTP client
└── Infrastructure (infrastructure/)
├── db.rs - SQLx 0.8 SQLite WAL connections
└── mailer.rs - Lettre 0.11 SMTP with retriesConcurrent Probe Pipeline
- Tokio scheduler ticks every 1000ms checking due monitors
- Semaphore limits to 100 concurrent probes
- Custom DNS resolver validates against SSRF blocklists
- Reqwest client executes request with 1-60s timeout
- State machine evaluates two-failure threshold
- Check logs batch every 5s to SQLite WAL
Key Features Breakdown
Zero-Signup Community Monitoring
Public monitors rotate every 10 seconds in the community pool, showing:
- Live status badges (UP/DOWN/PENDING)
- Target hostname with latency metrics
- Redacted sensitive data (headers/emails)
SSRF Defense-in-Depth
| Layer | Protection |
|---|---|
| URL Pre-Validation | Blocks 16+ forbidden CIDR ranges |
| DNS Filtering | Custom resolver defeats rebinding |
| Redirect Guard | Revalidates each 3xx hop |
Real-World Use Cases
- Indie Hackers: Monitor side projects without commercial tool bloat
- API Providers: Public status pages without user authentication
- Security Teams: Hardened monitoring for internal services
Performance Benchmarks
| Metric | Result |
|---|---|
| Probe Dispatch Latency | 0.8ms avg (P99: 1.2ms) |
| Memory Footprint | 28MB baseline, 42MB under load |
| SQLite Write Throughput | 1,200 logs/sec in batched mode |
Frequently Asked Questions
How does the SSRF protection work?
Three-layer validation: URL pre-screening, custom DNS resolution filtering, and per-redirect hop revalidation blocks all internal network access attempts.
What happens during network partitions?
The SQLite WAL mode with 5s busy_timeout maintains data consistency, while the in-memory queue buffers checks until connectivity restores.
Can I self-host this privately?
Yes – the Docker image runs unprivileged with just a /data volume mount for SQLite persistence.
Conclusion & Next Steps
Uptime Medics delivers enterprise-grade monitoring in a Rust binary smaller than most Node.js dependency folders. Its architecture proves that performance, security, and usability can coexist without compromise.
Try it now: https://uptime.nevatal.id