108

TL;DR:

Starting on the 8th of June, 2022, our status page will be updated automatically, bringing us closer to our goal of better communicating outage statuses with our community. The URL stackstatus.net will not change.

Long version:

The SRE (Site Reliability Engineering) Team has been working behind the scenes to create tooling that allows us to better communicate with everyone during site outages. With the final bits now in place, we will be migrating our status page from a manually-updated page (powered by Tumblr) to one integrated with our incident management tool.

The status page URL will not change. We will be updating the DNS record for stackstatus.net; the new page is actually currently live at https://www.stackstatus.net.

During an incident, we will be able to update the status page from within our incident management tooling, which removes a layer of friction that we previously had. We’ve also created internal tooling that will automatically update our Twitter account, @StackStatus, within our incident management tool, which will further help us share timely updates with the community.

17
  • 1
    Will an archive of the old Tumblr blog be retained? May 23 at 18:46
  • 4
    Currently we have no plans to delete the Tumblr, just to put one final post saying the status page has moved.
    – Josh Zhang StaffMod
    May 23 at 19:58
  • 1
    Couple of things... Firstly, the cookie banner refuses to go away for me (always comes back after a refresh.) Second, on the more recent updates, someone has managed to "like" the status, is that intended? Seems like an unnecessary thing, possibly due to how the site is related to Tumblr (which is also really odd!)
    – DavidG
    May 24 at 10:37
  • 1
    @DavidG those seem to be quirks of Tumblr which the "old" status page is built on.
    – Josh Zhang StaffMod
    May 24 at 12:49
  • 1
    Oh sorry, I didn't realise www and non-www sites were new and old and was looking at the old one, that's not immediately obvious in your post (to me anyway!)
    – DavidG
    May 24 at 12:55
  • 2
    I see the dates are in American, but are the displayed times in UTC? May 24 at 18:09
  • 2
    @AndrewMorton I believe the new status page localizes the time to your browser.
    – Josh Zhang StaffMod
    May 24 at 18:23
  • @AndrewMorton: There can be no serious ambiguity when the month is spelled out in words.
    – Kevin
    May 27 at 17:13
  • 1
    @Kevin That isn't what I was asking about ;) May 27 at 17:25
  • 9
    If the time display does not indicate which time zone it's using, there is no way to disambiguate whatever it is that it is displaying. Did this recent event happen two minutes ago, or three hours ago, or eight hours ago? (Or in the future?) How can I tell?
    – tripleee
    May 31 at 5:41
  • 3
    What went wrong? stackstatus.net is down. Jun 9 at 8:16
  • 1
    @ShadowWizardSaysNoMoreWar we put in a redirect for the apex domain stackstatus.net, redirects don't support https. http://stackstatus.net would redirect to https:/www.stackstatus.net
    – Josh Zhang StaffMod
    Jun 9 at 13:13
  • @JoshZhang no, stackstatus.net is not working for me as well. I don't have any browser extensions like https anywhere or anything like that. When typing http://stackstatus.net to my browser it loads for a long time and eventually showing "This site can’t be reached<newline>stackstatus.net took too long to respond". (screenshot). Jun 9 at 13:43
  • 1
    If I try to access https://stackstatus.net/ then I get a https everywhere message and, I too, can't load http://stackstatus.net/; the connection eventually times out.
    – Larnu
    Jun 9 at 13:53
  • 2
    I use https everywhere also and the redirect does break for me in some instances. Due to limitations of the tech sitting behind the new status page, the current http redirect is the only way it can work for the the majority of users. www.stackstatus.net will work for all cases.
    – Josh Zhang StaffMod
    Jun 9 at 15:40

7 Answers 7

46

Nice one! This looks like a lot of work for stuff that has low visibility (or, rather, which is only visible when things go wrong and the work is not ready yet), so it's important to say this: we appreciate it!

0
19

While this is no doubt a blessed change, I do have one concern at the moment: would it automatically update with every small incident e.g. short outage after publishing code changes? Or is there some threshold?

8
  • 17
    The status page will only show incidents classified P2 or greater, outages visible to the end user.
    – Josh Zhang StaffMod
    May 23 at 14:58
  • 8
    @Josh thanks! Forgive my ignorance but what's "P2" in that context? I remember it as point in geometry classes (e.g. line from P1 to P2) at school, doubt it means the same for you. ;-) May 23 at 15:18
  • 10
    Apologies for the internal lingo. P2 is what we consider a medium impact outage, anything affecting a large portion of the user base.
    – Josh Zhang StaffMod
    May 23 at 15:48
  • 17
    "P" in those stands for "priority", @ShadowWizardSaysNoMoreWar - it goes from critical (1) to very minor by incrementing the numeric postfix. The classification is often used for incident report classification (for example, Google's bug tracker uses exactly that). May 23 at 15:52
  • @Oleg huh, that makes some sense, yeah. No P0? ;-) May 24 at 6:16
  • 3
    @ShadowWizardSaysNoMoreWar Some such tools have them, but that level is more 'disaster recovery' than a normal (albeit critical) incident. For a hospital system, the medical record system going down would be a priority/severity 1 incident. A flood would be a p0/sev 0... but it's also the kind of thing that an IT team typically can't do much about because its outside their scope of support.
    – TylerH
    May 24 at 13:34
  • 1
    @ShadowWizardSaysNoMoreWar :) I don't recall encountering P0, but I guess that would indeed mean an "unmitigated disaster". May 24 at 15:16
  • @Josh Was the one just now a P2? Jun 1 at 7:18
15

Well, let's hope we don't have to visit it too often ... but it looks nice indeed! And responsive too, except for a minor on the history page. The forward button is not displayed; this screenshot is from Safari on an iPhone 11.

enter image description here

5
  • 7
    I'll create a bug report for this, thanks for pointing it out!
    – Josh Zhang StaffMod
    May 23 at 15:02
  • 8
    @JoshZhang Noticed a couple other odd bugs when browsing from my phone: 1) The Status part drops to a new line despite having plenty of space. Could even confiscate some of the excessive x-padding on small screens. 2) This icon doesn't maintain its circularness. Possibly shrinking due to a flexbox issue.
    – animuson StaffMod
    May 23 at 18:09
  • @animuson Change for an answer.. (nevertheless my comment will further increase the chance of someone reading your comment) May 27 at 13:38
  • These CSS bugs should now be resolved.
    – Josh Zhang StaffMod
    Jun 28 at 18:01
  • @JoshZhang confirmed, thanks!
    – Glorfindel Mod
    Jun 28 at 18:09
11

Is there also going to be manual feedback given by staff when outages occur or should we expect all messages on https://www.stackstatus.net/ to be automated?

1
  • 11
    Depending on outage severity and duration, there should be periodic manual updates to the status page along with the Twitter account.
    – Josh Zhang StaffMod
    May 23 at 19:57
10

When you say "updated automatically," do you mean that the site will detect instability or outages and proactively update the status, or that it will be automatically updated when an incident responder declares an outage?

Put another way, if your primary oncall is kidnapped1 by goons hired by your competitors, the site goes down, and everyone else sleeps through their pager, will the status site include a notification of that outage?


1 To be safely returned afterward, I'm sure.

4
9

Removing friction in reporting is always a good idea, particularly if it allows manual updates to long-running incidents but handles most updates automatically.

The current incident shows a null status when it was first created.

enter image description here

Also: I'm not sure that “milestone” is the correct word here. Milestones are fixed points within a process; they don’t move or transition. “Incident” would be a better word. And perhaps it shouldn't be bold.

4

There are currently four "services" listed on the status page: The SE Network, the API, SE.com, and Teams.

What about other services that SE runs, such as data.SE, or chat.SE? Those are often still up when we have outages, and have separate problems, and it'd be nice to know when / if they're down as well. (I'd also potentially suggest the blog as something that y'all might want to put on there.)

SO.com also runs slightly differently from the rest of the network, and might be worth splitting off of the rest of the network for the purposes of the status page.

1
  • 1
    Thanks for the feedback! The groupings are based on back end infrastructure. While SO.com is a bit differently than other SE network sites, it is ultimately a SE network site that runs on the same back end. Same with chat and SEDE. If we hit a situation where we need more granularity, we will adjust the status page as needed.
    – Josh Zhang StaffMod
    Jun 10 at 13:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .