Fudge Sunday - Cloud in Public: Status Dashboards

by Jay Cuthrell

View online

Start the week more informedThis week we take a look at public things for a public cloud.


This issue is part 1 of a 5 part series

  1. Fudge Sunday - Cloud in Public: Status Dashboards
  2. Fudge Sunday - Cloud in Public: Engineering SLO
  3. Fudge Sunday - Cloud in Public: DevCommsOps
  4. Fudge Sunday - Cloud in Public: Mean Time To RCA
  5. Fudge Sunday - Cloud in Public: Impact Mapping

Last Week

Razor Thin Margins of Error BarsRazor Thin Margins of Error Bars

Last week we took a look at three links and the implications in the cloud ☁️, attestation🔐, and statistical journeys to here be dragons🐲.


Last Week(s)

A look back at this week in…

This Week

This week let’s take a look at the history and evolution of the public status dashboard and what this means for the public cloud. We’ve come a long way but there is more to come in terms of transparency, personalization, and relevance.☁️✅⚠️🛑

Weekly Inspiration and Attribution

@cloudpundit says…

“The cloud is NOT just someone else’s computer”

– Lydia Leong aka @cloudpundit

Lydia Leong is a Distinguished VP Analyst at Gartner with both an active revered Twitter presence and a personal blog that is selectively syndicated to Gartner Blog properties. Regarding “media amplification of outage awareness” it is a good reminder that there’s always a XKCD (2347).


Earlier this week, I came across this Twitter thread and blog post from @cloudpundit. In a nutshell, ☁️ service provider transparency:


  1. Engineering Service Level Objectives (Engineering SLO)
  2. Service Architecture and Dependency Mapping (Impact Mapping)
  3. Status Dashboards
  4. Change Plans and Logs (DevCommsOps)
  5. Outage Root Cause Analysis (Mean Time To RCA)

This week in this issue, we’ll only be focusing on Status Dashboards as the first issue of five to come.🤓

  1. Summarize Dashboards ☁️✅⚠️🛑
  2. Contrast the past and present of Dashboards ☁️✅⚠️🛑

Status Dashboards Then ☁️✅⚠️🛑

Cloud historians point back to 2006 as the time of Amazon Web Services (AWS) entering the market. By 2008, AWS Service Health Dashboard was announced as a way to “provides access to current status and historical data about each and every Amazon Web Service”.

Originally, AWS Service Health Dashboard almost fit on one page scroll in a web browser. Today, AWS Service Health Dashboard involves scrolling multiple times per page and multiple regional tabs with their own scrolling multiple times per page.

The look of the 2008 AWS Service Health Dashboard was simple, clean, and brief with only nine (9!) services. (via Wayback Machine)

Today, +2000 services by region are represented on the AWS Service Health Dashboard.Today, +2000 services by region are represented on the AWS Service Health Dashboard.

By 2010, a status dashboard was becoming an expectation for customers of various “as a service” companies. Customers wanted to know if something was wrong with their Internet connect or if a service was truly having issues. See also: Social Telecom (2010) and Social Telecom 2030.

Paradise by the Stashboard LightParadise by the Stashboard Light

Paradise by the Stashboard Light was one in a series of technical blog post I authored for ReadWriteWeb (aka RWW). At the time, several online companies realized the need to offer status dashboards and Twilio responded by offering Stashboard which leveraged Google App Engine, an early precursor to the serverless movement.

Before the Stashboard project demo stopped working on June 20, 2017 and before the project was archived there were +300 forks on Github.


By 2016, status dashboards were commonly referred to as status pages. You can even find GitHub repositories that simply documented all the awesome status pages in existence – and those curate list repositories also saw forks!

By 2018, DevOps was almost a 10 year old concept. By late 2018, DevOps would come to decorate the names of status dashboards.

Public Cloud Status Dashboards Now ☁️✅⚠️🛑

Today, public cloud status dashboards are a more accurate way to think of an exhaustive status page. As compared to a simple SaaS company status page, a hyperscale public cloud service provider can have thousands of services that require a status report meaning many status pages must be represented in a status dashboard.☁️✅⚠️🛑

As one might expect, a personalized status page approach would filter and summarize the pertinent information to a specific customer. However, a personalized status page approach is a very recent concept in even in 2021.

In fact, only two (2!) hyperscale public cloud service providers offer a truly personalized status page at this time whereas. As for the others, the approach is decidedly do it yourself (DIY).

Historically, AWS launched Personal Health Dashboard in 2016 as a premium service while Azure launched Service Health in 2017 as a preview that became generally available in 2018 – at no additional cost.

Now, to round out this issue, reflect back to the five (5) areas that @cloudpundit outlined. It’s worth noting that beyond dashboard variation, there are still clear variations between hyperscale public cloud service providers today but those won’t possibly fit into this issue – hence the remaining issues in a series of issues to come.🤓

Work plug!

If you read this far, when you think about a multicloud journey, keep Faction in mind as a means to maximize access to hyperscale public cloud service provider innovations. Also… We’re hiring at Faction!🎉 See a fit for you or someone in your network? Please don’t hesitate to reach out to me.

One last thing…

I’ve been enjoying a few new newsletters – please check them out as well!


I am linking to my disclosure.

In order to unsubscribe, click here.

If you were forwarded this newsletter and you like it, you can subscribe here.

Created with [Revue by Twitter](https://www.getrevue.co/?utm_source=Start the week more informed&utm_medium=email&utm_content=footerlink&utm_campaign=Issue).

1903 Live Oak St #92 Beaufort, NC 28516-0092

✍️ 🤓 Edit on Github 🐙 ✍️