A developer looked at UptimeRobot, saw clutter, and decided to build their own. Not because existing tools don't work - they do - but because sometimes the friction of using something designed for everyone means it fits nobody perfectly.
The result is PingBoard, an uptime monitor with status pages, built using Convex for the backend, Clerk for authentication, and Resend for emails. The technical choices matter less than the thinking behind them.
The Decision to Build
Most developers face this choice weekly: use an existing tool that's 80% right, or build something custom that's 100% yours. The sensible answer is usually "use the tool" - building takes time, maintenance compounds, and you're trading product work for infrastructure work.
But sometimes the 20% gap matters enough. UptimeRobot works. Thousands of businesses rely on it daily. But its interface reflects years of feature accretion - every user request, every edge case, every "just one more option" layered into the UI.
For someone who wants to monitor five endpoints and display a clean status page, that complexity is friction. Not broken. Just... in the way.
The decision to build was about control and focus. Build exactly what's needed, nothing more. Own the experience end-to-end. Learn by doing.
Convex for Real-Time Without the Plumbing
The technical choice that shaped everything else: Convex for the backend. Not a REST API. Not GraphQL. Not serverless functions managing state in external databases. Convex handles database, real-time subscriptions, and serverless functions as one integrated system.
Why this matters for an uptime monitor: status needs to update live. When a site goes down, the status page should reflect that instantly, without users refreshing. Traditional architectures require WebSocket servers, message queues, and careful state management to achieve real-time updates.
Convex's reactive queries make it simpler. Write a query, and any component using that query updates automatically when underlying data changes. No subscription management, no connection lifecycle handling, no separate real-time infrastructure.
For a solo developer building quickly, this is the difference between "I can ship this in a weekend" and "I'll need two weeks to get real-time working reliably".
Background Workers and Heartbeats
Monitoring requires continuous background checks. Every minute, ping each monitored endpoint. Record response time. Detect failures. Trigger alerts. This workload doesn't fit the request-response model of typical web applications.
The solution: Convex's scheduled functions as heartbeat monitors. A function runs every minute, queries the list of monitored sites, performs health checks, and writes results back to the database. Because Convex handles scheduling and execution, there's no separate worker infrastructure to manage.
When a site fails multiple consecutive checks, the system sends an alert via Resend. When it recovers, another alert confirms restoration. Simple state machine, reliable execution.
This is the unglamorous part of building tools - the background work that makes the visible parts function. Get it wrong and alerts fire unreliably. Get it right and users never think about it.
Payments and Regional Limitations
Payment processing reveals geographic inequality in developer tools. Stripe dominates, but isn't available everywhere. Developers in unsupported regions face limited options - accept that some markets are inaccessible, or find alternative payment providers.
PingBoard uses Lemon Squeezy, a merchant of record that handles VAT, sales tax, and supports more countries than Stripe. The trade-off: slightly higher fees, less brand recognition, fewer integration examples in documentation.
For a product targeting global users, that trade-off makes sense. Better to pay 1-2% more in fees than exclude potential customers entirely. Regional access often matters more than marginal cost optimization.
What Building Teaches You
Shipping a tool people actually use - even a simple one - surfaces lessons that reading documentation never will.
You learn where latency becomes noticeable. A 500ms delay in a health check feels fine. A 500ms delay in page load feels slow. Same duration, different contexts, different user expectations.
You learn that error handling isn't about catching exceptions. It's about deciding what to tell users when things break. "Connection failed" is accurate but useless. "Could not reach your site - check if it's blocking our monitoring IP" gives someone a next step.
You learn that the features you thought were essential often aren't. The features you almost skipped become the ones users ask about most.
And you learn whether you actually enjoy building infrastructure. Some developers love it - the satisfaction of making something reliable, maintainable, and yours. Others find it tedious - they'd rather build product features and let vendors handle the plumbing.
PingBoard exists because the clutter of existing tools bothered someone enough to build an alternative. Not better in every way. Not more feature-complete. Just right for one person's needs, and possibly others who share them. That's often enough.