Thanks again !

Tbh we haven't thought of the sla violation

For region availability we are planing to add multi region check per Monitor

At the moment you can only set one region per monitor

I don't know much about statuses pages, I just check them to see if the services I use are having an issue. It's the first time I read about "synthetic monitoring", and from a quick Google search, it seems to referring to "automatic monitoring". A bsic versino of this would be to do a ping to see if the server is responding, or a HTTP request to see if it's returning a 200 status code.

However, if I read your comment carefully, you are suggesting to provide an alternative where the company (owner) could decide manually when a system is down or up. If that's the case, wouldn't the status page be just a page template where someone logs into a panel and toggle a button to say "down" or "up" and post updates? If there is no automatic monitoring, the service would look more like a blog/tumblr/twitter than anything else.

Or probably I am missing something because of my lack of experience and I am curious, I'd like to know!

Good question. Status sites usually advertise the availability of features. When your service to feature mapping is 1:1 with just a load balancer or a cache in between then it's relatively simple to calculate. The number of 500s on the load balancer, cache, or both indicates errors sent to users. As a company grows several services usually combine to form a single feature; think about how a company has a "sign in" feature. There's likely a service that handles typical username password auth, then one for SSO, one for passkey, etc... at this rate, you have several inputs but the outputs remain somewhat consistent. 500s seen on your most externally facing endpoints are errors to users.

Now combine all of the above with a client that has retry capabilities. That client could be a modern web app or a desktop app. Eventually consistent systems often rely on retry behavior and rate limiting to achieve smooth user transitions. Now I can't simply rely on 500s being sent because they may indicate a timeout or a caching problem. Now I need to rely on statistics on specific endpoints that will definitely result in a user facing error. Collecting that in real-time (real-time enough for alerting, anyway) is challenging as a company at that scale could be dealing with an abundance of requests per second.

When SREs get into an incident they'll often try to determine customer impact in order to know what hemorrhaging to stop first. Looking at a list of 500s in a system like that is often unhelpful, so we'll build dashboards of specific endpoints that show a level of degradation eg: "Show me all requests that did not have 2xx where the number of retries is 3". In my contrived example the client shows an error after the third exponential retry. If you were calculating availability purely off of the number of 500s you're not actually calculating customer impact, you're calculating the number of errors. That said it's a lot easier said than done to build a data system to make a query like what I described, much less to export it. So in order to provide accurate information the status site is updated manually.

On the flip side of what you described, some errors don't have a statistic. For instance, if I force rotate everyone's password and kill logins then I might post that on the status site as well. If it's the result of a security action or vulnerability I might declare the service degraded for a period of time.

Thank you very very much for taking the time to write this explanation. I learnt a lot today :)

> Why the focus on synthetic monitoring? As a SRE, I actively eschew synthetic monitoring. It's highly error prone and doesn't actually indicate regional availability. I'd like a status site that I could push a certain internally derived SLA for a given service to and the status site reflects the average over time of that windowed SLA.

As an end user, hard disagree.

GitHub is a great example of this. Their status almost always shows 100% uptime while the service is entirely unstable.

It is clear that their uptime SLAs do not align with end user experience.

As an end user, I care whether I can access and use the service. I don't care what broke in between.

I suspect on GitHubs front this has to do with how they populate their status site. They may update it manually once they identify customer impact. If they're using internal metrics to qualify the status site then they're likely not using all of the needed metrics to reflect customer impact. There's also a third possibility which is that between you and GitHub there's something that causes a partition or failure that is outside of GitHub and your domain of control.

I agree with you that the ultimate value is in customer impact. I was saying "that's hard" but synthetic monitoring is not the solution because it doesn't achieve what it sounds like it achieves.

> Why did you end up going with a SaaS model?

Convenience.

More companies want Datadog,etc than to manage Datadog,etc.