Keeping Everyone on the Same (Status)page

Brandon Viertel

Afternoon Higher Ed Community, 

We are in the process of rolling out the standalone public version of Atlassian Statuspage and wanted to gather input and opinions on your organization's implementation. I have come across quite a bit of other higher ed Atlassian Statuspages (kudos to you, Harvard and Kennesaw State) and it seems quite varied on what components were determined to be included. I wanted to start conversations on:

• What type of Statuspage are you using? (Standalone page(s) or included with Enterprise) 
• What version of Statuspage do you use? (Public, Private, Audience Specific)
• What do you deem as criteria to include?
• What was your thought process on granularity achieved for your components and categories?
• Have you setup any automated processes outside of the third-party integrations?
• What are your pain points/struggles with your current implementation?

Feel free to share a link to your Statuspage to showcase. 

Thanks!

Brandon Viertel

Nicholas Bentley

Hey Brandon,

We have a public Statuspage on https://status.eng.umd.edu. We are a bit unique in that this is the college-level vs the campus-level so our page is probably geared towards more niche tools but we do surface enterprise-wide tools on it as well (if they are other Statuspage customers/upstream providers that report to Statuspage, since they update automatically).

We typically include a service when it has a large number of users in production combined with an important business context. A lab tool we maintain for one faculty member would not make it there, but a core facilities management system that many faculty use would. There is no strict criteria but generally if something we are responsible for has a reasonable blast radius it is included on the page.

Automated tooling. There's a couple of things we did on this front that have been quite useful:

• We initially had automated incident creation but went back to human-in-the-loop because there is a lot of subjective reasoning that goes on when deciding whether or not to declare an incident.
• We have a custom Slack integration that I built on AWS Lambda that provides a higher level of customization than the default Slack integration provides (and also allows us to update incidents in Slack).
• We have some in-house web dev libraries that can pull status per-component to surface in various web properties. This gives us more granularity than the default widget & ensures we don't bug users who don't care about xyz service.

Statuspage has been one of the tools that has gotten out of the way for us for the most part. I think we'd love to see a more cohesive integration with Jira / Jira Service Desk/Management/Collection but that is not critical for us.

Nick