---
title: "Uptime monitoring with a status page, built by Claude Code on Elements"
author: "@chris"
author_url: https://elements.dev/u/@chris
published: 2026-09-30T21:01:50.016Z
url: https://elements.dev/demos/uptime-monitoring-with-a-status-page-built-by-claude-code-rntfd9ii
kind: post
format: article
---

# Uptime monitoring with a status page, built by Claude Code on Elements

by [@chris](https://elements.dev/u/@chris) · 2026-09-30

## Description

Checks your sites every minute, opens an incident after three failures, and runs a status page that emails subscribers.

Uptimebell needed a check of every site each minute, incidents that open on their own, a status page that updates as people watch, and email to subscribers. Each of those is a part of Elements, so the agent spent its 20 minutes on the monitoring itself.

- **Checks on a schedule.** One cron line runs a job every minute that queues one check job per monitor, keyed to the monitor and the minute, so a slow site holds up only its own check.
- **Incidents in one transaction.** Each check records its result, the day's rollup and the monitor's state together, and the third failure in a row opens an incident, posts its first update and schedules the alert email.
- **A live status page.** A channel announces each check and incident. The dashboard and the public status page listen for their own account and re-read through `@rpc` functions, so bars turn red and posted updates appear live.
- **Email to subscribers.** Visitors subscribe from the status page, and each incident update goes out as one background job per subscriber, so a retry reaches only the person it missed.
- **Data from SQL files.** Two migrations define the schema and seed two accounts with eight monitors on reserved example domains, 90 days of checks with outages, the incidents and updates that came from them, and subscribers. Two monitors fail on purpose and stay red.
- **Sessions.** Every dashboard rpc reads the account from the signed-in session.