In the interconnected world of 2026, a single minute of website downtime can lead to significant financial loss and a breakdown in user trust. During the AIORI-2 Hackathon, team DNinjaS from IIIT Pune addressed this by building a standards-based Website Health Monitor. By synthesizing protocols for data transport, reachability, and messaging, we created a system that doesn’t just watch websites—it understands their health according to the very rules that govern the Internet.
1. The Multi-Protocol Health Stack
Our monitor, built on the Django framework, acts as a protocol orchestrator. We don’t rely on a single metric; instead, we implement a multi-layered check system based on foundational IETF RFCs.
- HTTP Semantics (RFC 9110–9114): The core of the check. We use Python’s requests library to validate status codes (e.g., 200 OK vs. 404 Not Found or 500 Server Error).
- ICMP Reachability (RFC 792): A lower-level “ping” to verify if the server hardware is reachable, even if the web service itself is failing.
- JSON Communication (RFC 8259): We use JSON-formatted AJAX calls to ensure the dashboard updates in real-time without requiring a browser refresh.
2. System Architecture & Real-Time Observation
Monitoring is only useful if it is continuous. We integrated Celery with Redis to create an asynchronous task queue. This allows the system to perform hundreds of health checks in the background while the user navigates the dashboard.
The Workflow:
- Trigger: Celery beats at a defined interval (e.g., every 60 seconds).
- Check: The worker executes an HTTP/HTTPS request, verifying the TLS 1.3 (RFC 8446) handshake.
- Analyze: Response times and status codes are logged into an SQLite database.
- Alert: If a failure is detected, an In-App notification is triggered immediately.
3. Implementation Metrics
| Feature | Standard (RFC) | Implementation Detail |
|---|---|---|
| Status Logic | RFC 9110 | Logic based on HTTP response class (2xx, 3xx, 4xx, 5xx). |
| Real-time UI | RFC 8259 | AJAX polling every 5–10 seconds with JSON payload. |
| Security | RFC 8446 | HTTPS certificate validation and TLS version check. |
| Messaging | RFC 5321 | SMTP-based email alerts (In development). |
4. Technical Challenges: The Timing Problem
During the sprints, we encountered a significant hurdle with asynchronous timing. Our Celery intervals occasionally drifted, executing checks more frequently than scheduled (e.g., every 7 seconds instead of the intended 15).
- The Fix: We tuned the Redis broker visibility timeouts and implemented a “last-checked” timestamp in the database to prevent redundant overlapping tasks. This ensures our monitoring is both persistent and resource-efficient.
5. Lessons from the AIORI Testbed
Our experience proved that “Internet Health” is more than just a binary UP/DOWN status. By mapping our system to RFC 9110, we learned to interpret nuanced failure states—such as a site being “reachable” via ICMP but “broken” via HTTP.
“Implementing this framework taught us that small configuration issues, like Celery intervals or SMTP credentials, are the difference between a reliable monitor and a false alarm.” — Team DNinjaS
6. Future Work: Closing the Alert Loop
Our next sprint involves finalizing the Multi-Channel Alerting engine. We are integrating:
- SMTP (RFC 5321/8314): Automated email escalations for critical downtime.
- Web Push (RFC 8030): Direct browser notifications even when the dashboard tab is closed.
- AIORI-IMN Integration: Using distributed nodes to check if a site is down globally or just in a specific region.
