SiteBleed

There's a moment that stuck with me.

A friend who runs a Shopify store called me after a 4-hour outage. He found out because a customer texted him. Not his monitoring tool — a customer.

When he finally got back up, the obvious question was: "How much did I just lose?" He opened Shopify analytics, tried to estimate it against a typical Saturday afternoon, did the mental math. He never got a clean answer. Just a vague sense that it was bad.

That bothered me. He was paying for a monitoring tool. It told him when he went down and for how long. But the question that actually matters to a business owner — what did this cost me? — was left as an exercise for the user.

The existing tools had this problem

I looked at every uptime monitor I could find. UptimeRobot, Better Stack, Freshping, Pingdom, StatusCake. They all solve the same problem well: is my endpoint responding?

But they're built for a DevOps frame. SLAs, response codes, P99 latency. Completely valid for someone running infrastructure.

For an e-commerce store owner, that's not the mental model. They think in: hours × conversion rate × average order value. They think in dollars, not uptime percentages. Nobody was building for them.

What I built

So I built SiteBleed. The pitch is simple: when your site goes down, you see a live counter — not just a red status light, but the estimated dollar amount you're losing in real-time, based on your own numbers.

You enter your monthly revenue when you set up a site. That's it. SiteBleed pro-rates it to an hourly rate, starts the counter the moment a downtime event begins, stops when you recover. Every incident has a revenue impact attached to it. When you go to explain an outage to your team or a client, you have a number — not a feeling.

The rest is what you'd expect from an uptime monitor: 5-minute checks, Slack/Discord/Teams/email alerts, SSL and domain expiry warnings, TCP and port monitoring, public status pages, maintenance windows, SLA tracking, team seats. I didn't skimp on the table stakes. But the revenue loss piece is what I keep hearing about.

What's surprised me

The embeddable badge has been a sleeper hit. One image tag, live uptime status in your README or status page. Users started adding it almost immediately, and it keeps showing up in places I didn't expect — which also means it keeps showing up in front of people who don't know SiteBleed yet.

The onboarding email sequence has been the other surprise. I assumed nobody reads them. Turns out a 6-email sequence that walks you through the actual features drives real activation — users who reach email 3 convert to paid at a noticeably higher rate than users who don't.

What hasn't worked: vague "monitor your website" messaging. When I made the CTA specifically about knowing what downtime costs you, conversion improved. The more concrete the pain, the better.

What I'd do differently

Ship the revenue tracking feature first. I built all the monitoring infrastructure before I got to the revenue loss piece — I thought it was a nice-to-have on top of "real" monitoring. It turned out to be the reason people signed up.

If you're building in a crowded category, the feature that makes people care is the one that reframes the problem, not the one that does the existing thing slightly better.

Where things stand

SiteBleed is live at sitebleed.com. Free plan covers 1 site, paid plans start at $19 CAD/month. I shipped a public REST API last week so you can query your sites and incidents programmatically — docs at sitebleed.com/docs. There's also a public changelog and a blog covering uptime for e-commerce operators, both small compounding bets.

If you're running a store and you want to see what downtime actually costs — not just that it happened — give it a try. Free, no credit card.

Happy to answer questions about the build, the stack, or anything else.