The architecture decision that makes a sustainable free tier possible.
Most uptime monitors check your site every few minutes and store the result: "up, 142ms response time." Next check: "up, 138ms." Next: "up, 145ms." Over and over, 480 times per day per monitor.
If your site is up 99.9% of the time, you're storing hundreds of identical "still up" rows every day. Multiply by thousands of monitors across thousands of users, and you've got a database problem.
This is why free tiers keep shrinking. UptimeRobot restricted theirs to non-commercial use. Freshping shut down entirely. The storage costs of serving free users become unsustainable.
We took a different approach.
What actually matters isn't "is the site still up?" — you already know that. What matters is when the status changes. Up to down. Down to up. Those transitions are the events you care about.
So we only store transitions. A monitor that stays up all day generates zero database rows. A monitor that goes down once and recovers generates exactly two rows: one for the down event, one for the recovery.
Traditional approach
Store every check result
3-min checks = 480 rows/day/monitor
1,000 users × 20 monitors each:
9.6 million rows/day
~13 GB/week
Transition-only
Store only status changes
99.5% uptime = ~4 rows/day/monitor
1,000 users × 20 monitors each:
80,000 rows/day
~100 MB/week
99.2%
less data. Same information. Full uptime history reconstructable.
"But how do you calculate uptime percentage without every check result?"
Simple: sum the duration of UP intervals, divide by total time. If the transitions say:
UP at 00:00
DOWN at 14:00
UP at 14:05
UP duration: 14h + 9h55m = 23h55m
Total: 24h
Uptime: 99.65%
This is actually more accurate than the traditional approach, which only samples at check intervals. We know the exact second status changed, not just "it was down sometime between 2:00 and 2:03."
Sustainable free tier
Free users cost us almost nothing to store. So the free tier isn't going anywhere.
Faster queries
Scanning thousands of rows instead of millions means your dashboard loads fast.
Accurate uptime
Exact transition timestamps give more precise uptime percentages than sampled checks.
We learned this the hard way. A previous project stored every check result and generated 67 million rows per week at just 1,000 users. The "scaling problem" that consumed days of analysis was entirely self-inflicted. Ten minutes of schema design would have prevented it.
If you're building anything that records periodic state, ask: "Am I storing the same value over and over?" If yes, store transitions instead.