Services like Cloudflare and Twilio have so many POPs globally that one or more always have an outage going on. Then there's the question of whether it's a major outage or a minor outage. Even though major status page providers like Atlassian and Incident.io have public status APIs (Cloudflare uses Atlassian), it takes more than just parsing them to determine what is "down" and at what granularity.
I run an outage detection service - and some of these issues, like parsing hundreds of - sometimes undocumented - status APIs, make for an interesting engineering problem.
I understand this is an initial launch, so not trying to nitpick, but these are what felt like would add immediate value:
- Adding a social login like Google would allow faster signups.
- Maybe I missed it - but I could not find any options for automatic monitoring which would update the status page. There are manual options for adding an incident.
- Post-signup, it takes me to a login page. Why ask to enter the company name instead of user/pass directly?
- If I could click on "Components" on my dashboard (/admin) and go directly to the Components page, that would be nice.
I like it that you took the time to write a privacy policy that is both readable and precise, especially as to the list of third-party services.
Working on my SaaS that monitors third-party status pages - https://incidenthub.cloud/ It's a one-person project I started last year.
My biggest technical challenge remains dealing with the immense number of different APIs (and not-APIs) in the different status pages out there. Marketing remains my biggest overall challenge as my background is engineering, but I've learnt quite a bit since I launched this.
I see what you are describing. The pre-production/staging setup may not bring out cost increases caused by application changes, and by the time it is running in production for a while it has already caused a cost explosion.
We did face similar situations - but we fixed them after the cost went up on prod. I guess this has more to do with how much and how fast an "undetected" cost in pre-prod can explode in production. We used to keep an eye on the prod cost numbers after a deployment, and then tackle each one, because the increase was not that quick.
I'm not sure either about a "standard" way, so I'm just thinking aloud here, and I've not tried this myself:
For application changes, measure the difference in cost in pre-prod, in terms of percentage increase, between the previous deployment and the current one, and use that to estimate the possible prod increase. I suspect this will become messy very fast as the other factors to include would be num requests, CPU/memory usage, and so on.
Rather than focusing on accountability as the starting point, I would suggest building tooling and visibility so that cloud costs are visible across all layers including application and infra. Once you have this, accountability becomes easier.
Each application team should be able to view the total cost of running their service - and thus be held accountable to reduce costs when necessary.
Without data you are running blind. Cost optimization cannot be solved by a standalone team - it has to be owned by everyone.
Source: Personal experience reducing cloud costs in a slightly smaller team.
Building incidenthub.cloud