Pulse Uptime

When production breaks, the first question is: us, or our providers? Pulse answers it. Your checks beside live OpenAI, Stripe, and 30+ provider status, clear alerts, and an agent can run all of it.

Comment

Inspiration

On the first day of the hackathon, while I was still ideating, the server I use to host my old PHP websites went down. Someone had tried to hack a WordPress deploy on it. I only found out the next day, from an email sent by a WordPress plugin that happens to watch for downtime. One plugin, on one site, was the only reason I knew at all.

That felt like the right itch to scratch. I wanted uptime monitoring I could deploy myself in minutes, that costs almost nothing to run, that is easy to use and nice to look at. I also wanted it to have a CLI from day one, so that going forward Codex could manage it for me and help me out if anything went wrong. And it sounded like fun to build.

What it does

Pulse checks your endpoints, confirms failures, opens incidents, and sends one clear alert per outage. Beside your own checks it mirrors the published status of 20+ providers, so when Vercel goes down three minutes before your app does, Pulse shows you the overlap. Every deployment serves a public status page from live monitor state. A typed API and the pulsectl CLI give people, scripts, and agents the same control plane. You can paste one prompt and your agent will install the CLI, link your deployment, and manage monitors for you.

How I built it

I started with a ChatGPT session to shape the plan. I talked through the features I wanted, where it should run, and the constraints, especially fitting entirely on free tiers. There are plenty of hobbyist developers who would use something like this but do not want to pay for infrastructure, and I wanted Pulse to work for them.

While I was ideating, a friend texted me that WorkOS was down, and with it his whole day. That crystallized the second idea. We all sit on top of dependencies. If you already have a tool watching your own uptime, why not roll your dependencies into it too? So Pulse mirrors the published status of 20+ providers beside your own checks.

Pulse is Vercel-native and Postgres-backed. Vercel Cron schedules checks, Neon stores history, Edge Config serves zero-database reads, and Resend delivers alerts. No queues, no workers, no servers to babysit. Storage stays within a configured budget by compacting routine checks into rollups while preserving full detail for incidents. The checker treats everything as hostile. It validates every DNS answer, pins the socket to the resolved address, refuses private and link-local ranges, and caps provider feeds at 512 KB with entities off.

Challenges I ran into

I started coding on the 17th and I am writing this on the 21st. The first four hours produced the first 80 percent of the project. The next 92 hours went to the final 20 percent.

That last stretch was all about nailing performance and security, and hammering out the oddities of a purely generated codebase. Code with no historical shape to it fails in unfamiliar ways. Nobody ever made the small decisions that normally accumulate in a repo, so I had to go find every place a decision was never really made, then make it properly. Hardening the checker against hostile targets, confirming outages without alert storms, and keeping history inside a hard storage budget all lived in that 20 percent.

What I learned

I picked up some new services along the way. I had never built with Edge Config in Vercel before. But the biggest learning was how to actually use GPT Pro.

I wrote a few reusable prompts that swept the codebase for bugs, security holes, and badly named functions whose names hid what they really did. Doing those sweeps myself would have taken a day each. With Codex, probably a couple of hours. GPT Pro worked for 60 to 80 minutes and came back with the discoveries and a plan for how to remedy each one. The lesson was to stop treating long-running review as a chore I do and start treating it as a job I dispatch.

I also used ChatGPT Sites for the first time, to host the marketing site. I was nervous about putting any complex framework on it, so the site is just HTML, CSS, and vanilla JS. Turns out ChatGPT Sites can handle a lot more than that. Not a massive learning, but next iteration I will definitely push it further.

What's next

I tried to nail as much of the roadmap as possible before submitting. Now I am opening Pulse up to the public to get feedback and see how it goes. Hopefully it is valuable to others.

The goal from here is boring on purpose. I want to let it run for the next decade without needing a ton of changes. And I am thankful, because none of this would have been possible without Codex.

Built With

Share this project:

Updates