Status page for NodeJS

[MattIPv4]

Latest status for the new status page

The experimental and very W.I.P status page is now available at https://status.nodejs.org/

We are currently working on establishing the policy for what should be posted on the status page and who should have access to it.

Open tasks & questions

• What is an Incident?: StatusPage: What is an Incident? #2303
• Who should have access?: StatusPage: Who should have access? #2304

Any discussion not related to these specific topics should be kept in this issue (unless a dedicated issue is then created for said topic).

Draft PRs

• build: Docs & customisation backup: StatusPage #2299
• website: Adding embed & link to status page: feat: Statuspage nodejs.org#3126

These PRs should not be landed until the status page is ready to go completely.

---

Original issue

Hey folks,

The current crisis (nodejs.org intermittently returning 500s) has prompted a thought that perhaps having a proper status page for NodeJS would be a great canonical location to be able to communicate with the community that the NodeJS folks are aware of issues.

This would help with reducing the number of issues being created for the incident and would reassure the wider NodeJS community that folks here are looking into any issues.

I'm not proposing any automation here (unless someone wishes to add metrics) -- automation of status pages is often frowned upon, as it then isn't that helpful, only showing what folks already know, instead of acting as an acknowledgement that humans on the project know something is wrong.

As NodeJS is an established open source project, it should be possible to get an open-source license from Atlassian to use StatusPage: https://www.atlassian.com/software/views/open-source-license-request -- I have previously done this for cdnjs (status.cdnjs.com) and it works perfectly.

---

As a POC, assuming blessing from NodeJS folks, I would be happy to reach out to Atlassian and start the licensing process. Once acquired, I'm quite happy to stand up a POC status page on status.node.js.org (js.org, not the node-owned domain) and build out the page (styling, components, etc.).

Once that's done, the page can then be reviewed and if happy with it, it can be moved over to status.nodejs.org (all that's required is a CNAME to the statuspage site), and folks that need access can be invited.

I think it'd be best to invite as many NodeJS folks as possible, so that during an incident hopefully someone will be around with access to post updates to the status page.

[daniel-white]

It would be great if there was twitter account that one could follow the status updates akin to githubstatus.

[MattIPv4]

Yeah, totally. StatusPage comes with Twitter support (@cdnjsStatus for example). I think that'd likely be a step after getting the initial status page stood up, but shouldn't be hard.

[joepie91]

As NodeJS is an established open source project, it should be possible to get an open-source license from Atlassian to use StatusPage: https://www.atlassian.com/software/views/open-source-license-request -- I have previously done this for cdnjs (status.cdnjs.com) and it works perfectly.

I don't think it's necessary (nor desirable) to add proprietary infrastructure like this, to what's supposed to be an open-source project.

There are plenty of open-source off-the-shelf status page systems readily available, such as Cachet.

[MattIPv4]

Sure, using an open-source alternative would be an option. This though then requires more infra on the NodeJS side to run it and could end up in the same basket as the incident itself if there is a major outage.

StatusPage is the industry standard for this, has a free licensing option dedicated to open source projects such as NodeJS, and is off-site so that it will very likely remain up even if NodeJS has a major outage.

[joepie91]

This though then requires more infra on the NodeJS side to run it and could end up in the same basket as the incident itself if there is a major outage.

It's commonplace to host the status page on different infrastructure than the thing that the status page is for. That can be something as simple as a $3/month VPS at a random provider. I don't think this is an unreasonable ask.

Sure, the status page can still go down, but the same is true for a hosted service. In fact, a hosted service would give you less control over infrastructure separation, since the provider may choose to internally move their systems to the same infrastructure that your things are running on, and you cannot control that.

has a free licensing option dedicated to open source projects such as NodeJS

Sure, but it is still proprietary infrastructure, plus such a license could be revoked at any time with no recourse. IMO there's a pretty high bar to consider making an open-source project depend on proprietary infrastructure, considering that it negatively effects eg. the forkability of a project (as the infrastructure of a project can't necessarily be freely replicated anymore).

Considering that there are polished off-the-shelf open-source options available here, and hosting them is low-complexity, I don't think that bar is met here. And it's a bit strange to me to immediately suggest using a proprietary service without investigating open-source options first.

Edit: Would those liberally sprinkling around downvotes, care to make an actual comment? Just downvoting things is not helpful at all.

[MattIPv4]

I don't disagree that using an OSS option has its benefits, as you've outlined.

However, as I mentioned before, StatusPage is the industry standard for this and has a rather proven track record for being a good option. There's a reason they're used by a large body of reputable companies (e.g. https://www.cloudflarestatus.com/, https://status.digitalocean.com/, https://www.githubstatus.com/).

I've gone through a very similar process to this when setting cdnjs up with a status page, and StatusPage became the chosen option then, so it has my absolute recommendation here.

[joepie91]

I've gone through a very similar process to this when setting cdnjs up with a status page, and StatusPage became the chosen option then, so it has my absolute recommendation here.

Do you have any documentation of the process and the considered options and their pros and cons anywhere?

Technology decisions don't generally carry over between projects because different projects have different requirements, so it's important to look at the actual underlying considerations here.

[MattIPv4]

Do you have any documentation of the process and the considered options and their pros and cons anywhere?

Nothing documented, as this decision was made internally. Essentially though the considerations were costs involved, reliability & confidence that the option would work out of the box. StatusPage won out there as it was free, is incredibly reliable as demonstrated through its mass of customers and I trusted it to just work, again, based on the incredible number of reputable customers.

[sam-github]

This will come up in the retrospective, #2264 , but from my point of view we have issues pinned at the top of https://github.com/nodejs/node/issues and the top of (since I just did it) of https://github.com/nodejs/build/issues.. I appreciate that people would like notifications from their tool of choice (status page, twitter, etc.), but that seems a big ask for a project of this size (size in terms of people volunteering to help maintain the infrastructure).

[MattIPv4]

I personally don't think a pinned issue on one or two repositories should be regarded as sufficient communication/notification for such incidents.

A status page would appear to the average user as a far more official and canonical source of information for incidents (imo) and would allow folks to quickly find official updates, which is rather hard in the messy issues full of "also seeing this" etc.

but that seems a big ask for a project of this size (size in terms of people volunteering to help maintain the infrastructure).

I honestly don't see this as a big ask at all. Assuming the use of StatusPage, there isn't really any requirement for folks to maintain any infra, StatusPage look after all that. The only other ask would then be for someone to ensure an incident is posted on there when something goes wrong and to update it as appropriate until the incident is resolved.

[fishcharlie]

Wouldn't StatusPage also help alert the Node.js team members in a quicker fashion? Maybe that could help jump start on fixing things instead of having to wait for user reports of a problem?

I do agree tho. For outages, GitHub issues doesn't feel like an obvious place I'd check for that information.

[joepie91]

A status page would appear to the average user as a far more official and canonical source of information for incidents (imo) and would allow folks to quickly find official updates, which is rather hard in the messy issues full of "also seeing this" etc.

Can this not just be addressed by pinning and locking the thread?

[MattIPv4]

Wouldn't StatusPage also help alert the Node.js team members in a quicker fashion? Maybe that could help jump start on fixing things instead of having to wait for user reports of a problem?

Twofold, depending on whether automation is used. If automation is used and detects the outage, it could be set up to automatically mark a component as having an issue. Anyone should then be able to subscribe to that to get alerts through their service of choice.

Equally, StatusPage has really good support for firing off alerts whenever an incident is posted or updated, which again anyone could subscribe to so that they can be notified when something happens.

Can this not just be addressed by pinning and locking the thread?

Sure. That helps a significant amount (though it hasn't been done here and resulted in a very messy set of threads). However, as I said above I personally don't feel that GitHub issues are the correct medium to be used for declaring & tracking incidents of this scale for the greater community.