Uptimebell: uptime monitoring and a public status page for web teams
Checks your sites every minute, opens an incident after three failures, and runs a status page that emails subscribers.
Agent specs
- Agent
- Claude Code, Opus 5.5 Medium
- Time
- 20 min
- Cost
- $6.06*
Agents work faster and more accurately on Elements.
* Cost at API rates, September 2026.
Run it yourself
Paste this prompt into your AI agent. You get the finished app on your own machine, ready to change however you like.
Install elements: curl -fsSL 'https://install.elements.dev?os=darwin' | sh && export PATH=~/elements/bin:$PATH Create an Elements app from the elementscode/demo-uptimebell scaffold: cd ~/elements/projects elements create uptimebell -scaffold=elementscode/demo-uptimebell cd uptimebell Start the app.
How it's built
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.
What Elements gave the app
- 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
@rpcfunctions, 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.
What the project server gave the agent
The project server runs alongside the agent and answers as soon as a file is saved: it type-checks the templates, TypeScript and SQL, applies migrations and reruns the tests, so every question came back right away and the agent kept building.
What shipped
The app type-checks with zero errors and all 29 tests pass. Every page works on desktop and phone, and live updates arrive across tabs, such as an incident update reaching an open status page.
The code
Build it from scratch
To watch your agent build this app from an empty project, use the prompt we used instead. It takes longer than starting from the finished app above.
Install elements: curl -fsSL 'https://install.elements.dev?os=darwin' | sh && export PATH=~/elements/bin:$PATH Create an Elements app: cd ~/elements/projects elements create uptimebell cd uptimebell Start the app, then build this: Build an uptime monitor and status page named uptimebell. - Accounts; each account adds monitors: a name and a url, checked every minute. - A background job requests each url and records response time and status. Three failures in a row opens an incident and emails the account. - Dashboard: each monitor's current status, response time chart for the last 24 hours, and uptime for 24 hours, 7 days and 90 days. - A public status page per account with a component list, a 90-day bar per component, and incidents. - Post incident updates (investigating, identified, resolved); subscribers to the status page get them by email. Seed two accounts with monitors (some pointing at urls that fail), 90 days of check history, and past incidents. Show the seeded logins on the sign-in page. Statuses, charts and incidents update in real time on the dashboard and the status page.
Comments· 0