You're browsing your favorite website, clicking around, when suddenly, you're rudely interrupted by a white screen, proclaiming: (I don't mean to pick on Varnish cache here, It's just a screenshot I had handy) As a developer, my eyes scan error messages like these for numbers - in this case, the "503" - indicating that the error isn't my fault, and I can move on with my life.

Last Saturday, our API went down. Not even a funny error message or slightly slower responses either, it just completely vanished off the internet for 18 minutes. I'm not normally one to point fingers at my hosting provider when things go wrong (since ultimately, I chose to use them, so it's my problem to fix), but when fly.io publicly posts on their forums about their reliability issues, I may as well link to them.

I'm excited to be launching onlineornot - OnlineOrNot's newly-built, open source (TypeScript) CLI for managing your uptime checks, all from the comfort of your terminal!

Two years ago, OnlineOrNot started as a little toy app I built in an afternoon to see what it's like using the Next.js framework, to see if a URL is down from around the world. I gave myself a week to turn that toy into a SaaS people could pay for. It looked like this when it went live: It wasn't ready for real users, but that didn't matter. I had something out there, that people could sign-up for, tell me what they were expecting, and how OnlineOrNot fell short of their expectations.

It's a story as old as the web itself: someone on your team gets excited to install a new tool. The tool promises to finally give you a clear view into the problems your users have with your product. Your team agrees to give it a go. The errors start coming... ...and they don't stop coming... Soon enough, most of your team has either created an email filter to manage all the alerts, or has unsubscribed themselves entirely. Just like all the other tools. Welcome to alert fatigue.

It's fairly common for folks in tech to dream of quitting their day job and working on their side projects. I find when you ask them how their projects are going, they tend to have 2-3 projects running at the same time, none of the projects are actually available for potential users to try out. The question they seem to ask me most is "you seem to complete your projects, how do you stay motivated?" My secret? It's a habit. I ship something every day.

In case you missed it, Hacker News had an extremely rare outage last week.

The other day, a friend told me about fly.io's nice developer experience (DX). For my day job, I work on improving wrangler2's DX, so naturally it had me curious. I went from "I'll just play around with it, maybe give it a toy workload" to "holy shit, what if I quickly rewrite my business's AWS Lambda + SQS stack to fit entirely within their free tier" in about 90 minutes. It wasn't that simple in the end, but I did manage to migrate most of my active workload from AWS Lambda to fly.io.

This time last year, I showed the internet a little prototype uptime checker I built using Next.js as the frontend, with services running on AWS Lambda. I gave myself one week to put it together. I wrote a few articles about how the business was going throughout the year: The gist of my approach is as follows: I started with a single Lambda function that checks if static websites were still online, added an email alert if it's offline, wrapped authentication around it, integrated Stripe, and shipped it.

Jumping into monitoring software for the first time can be pretty overwhelming. If you're not in an exploring mood, it can be easy to get lost, and you're not entirely sure what all these knobs and buttons do. To help lighten this feeling for OnlineOrNot, I thought it might be useful to let folks know how I use OnlineOrNot, to monitor OnlineOrNot (as part of running OnlineOrNot day to day). Also, our friends at DebugBear wrote a similar article about how DebugBear uses DebugBear to keep their site fast.