Hey PH 👋

Maker here. Built this because I was tired of customers telling me our service was down, only to realise it was actually one of the Cloud/SaaS providers we depended on.

The annoying thing about running anything online: your app is basically duct-taped together with a dozen different services: AWS, GCP, Azure, Stripe, GitHub, OpenAI, Twilio, whatever, and when one of them breaks, you sometimes find out from your users before you realise that one of they Vendors you rely on is the cause of the outage. Most major vendors have a public status page. Usually, nobody checks them until shit hits the fan. Pingoru monitors all your vendors' outage updates every ~5 mins, and if any vendor reports an outage, we'll send you a notification.

With Pingoru, you pick the stuff your stack actually depends on, and get a notification the moment something goes sideways with one of the providers you rely on.

You can drill it down to the components you actually use. EC2 us-east-1, not every AWS service. Stripe Checkout, not the 170 other things they track. So you're not getting pinged every time EC2 in N.Virginia goes down, even though your instances are hosted in another region that’s not experiencing any issues.

What we do differently from other status-page aggregators:

Maintenance isn't an incident.

Other status page aggregators mash them together (or don’t notify about maintenance at all), and your history ends up cluttered with "Maintenance Scheduled in 7 days" entries. Not downtime right now, but an alert by your provider that they are scheduling maintenance with potential downtime (DB upgrade, etc). We have given maintenance its own dedicated page and calendar view. You can see what's scheduled across your provider stack, what's in progress right now, what’s scheduled and what's wrapped up.

One last thing, before anyone else brings it up! As you probably know, vendors can be unreliable/sporadic about updating their status pages in a timely manner when their stuff's actually broken. And when they do decide to update their Status Page, their service may already have been experiencing issues for a while.

This is a gap, and I’m aware of it! So we’re working on a way to gather a community “pulse” to determine whether a vendor is having issues before they report them themselves. Down Detector does this well by gathering community reports https://downdetector.ca/. But we don’t currently have the traffic and reporting services required to make that work reliably, even if we did start collecting user downtime reports.

At least with Pingoru, you've got the receipts. When you need to prove the downtime was a vendor's fault, not yours, the history's there. This is great when you have Service Level Agreements (SLAs) with your customers and need historical/postmortem data on why/when you had outages.

Finally. Question - Tell me the vendor that's burned you the worst with a silent outage - The one you wish you'd known about 10 minutes earlier?

Cheers,

Tom