drupal.org error 500 page twitter widget is unusable

Thank you for opening this @podarok - a Mastodon replacement is a good idea, I think. Or a proper status page service.

Status page service not that easy, because of a dedicated maintenance needed
Mastodon on other hand - just a twitter like feed anyone or drupal_infra team can push messages to without additional effort or human onboarding

I suppose an account could be opened on https://drupal.community and some tool like https://gitlab.com/idotj/mastodon-embed-feed-timeline could be leveraged to replace the embed on 500 error pages.

We’re trying a few ways to read the feeds.

There are some discussions and tests being made here: https://drupal.slack.com/archives/C1BMUQ9U6/p1688665965950989

Once there is a consensus i can update here too.

Option 1: Using aggregator module and exposing the blocks: https://fjgarlin-drupal.dev.devdrupal.org/security
Option 2: Using https://github.com/andy-blum/fed-embed with minimal styling (max-height and overflow): https://fjgarlin-drupal.dev.devdrupal.org/about/core

We know that option 1 would need some additional coding to expose aggregator blocks into panels UI, and probably additional styling; and 2 would only need a little bit of styling, but wouldn’t leverage the server-side caching of aggregator.

For the 5xx error page, option 2 would be the only one available (unless we use another solution like the one suggested in #6).

Option 3 - iframe of profile at mastodon

https://www.drupal.org/about/core → now has the Twitter embed replaced with a feed from Mastodon that updates hourly with Drupal’s aggregator module. This avoids any privacy/performance/etc considerations for loading 3rd-party JS.

That of course won’t work for Drupal.org’s 500 error message. I think it would be best to replace it with the right tool for the job, a link to a status page.

I investigated using our existing monitoring & alerting tools, DataDog & Opsgenie, since they have some incident management built in. Neither looked like a clear improvement for our use case; and their integrations with public status page services look like they could be clunky in mapping fields across. We might end up having to log into another service, which is not what we want to do when troubleshooting an incident.

The best fit looks like incident management on GitLab.com. (Not on git.drupalcode.org so we can update the status page when it is offline.) We can make templates for different incidents, create & update incidents, and a pipeline publishes a static page to S3.

Looks great, @drumm

What if we just embed mastodon page without introducing rss or aggregators?
There are services which help now ( e.g. alias https://mstdn.social/@drupal_infra@bird.makeup ) and iframe should work perfectly for https://drupal.community

Consider including/embedding https://mastodon.social/@drupalinfra.rss.

Ha, @hestenet you beat me to it :) Just came here to say the same! Updated the IS and screenshot.

A Simple discussion repo in GitHub can do it.
under https://github.com/drupal .. like
https://github.com/drupal/drupal-infra or https://github.com/drupal/drupalorg-status or ...

• @drupal_infra on Twitter/X - last updated 3 months ago, lately only shows planned outages, has intuitive threading (first report shown first, follow-ups threaded underneath).
• @drupalinfra on Mastodon - last updated 3 days ago, shows both planned and unplanned outages, has an unintuitive threading (follow-ups show up first, hard to find the original incident report).
• #drupal-infrastructure on Slack - last updated 12 hours ago, shows early incident reports, direct support from infra maintainers, is intuitively threaded (first report shown first, follow-ups threaded within).

Having a third-party hosted incident report / status page would be super nice, and there are plenty to choose from:

• GitLab.com incident management mentioned 2 years ago in #10.
• GitHub Discussions was mentioned in #16.
• Atlassian Status Page is the industry standard, but is also ridiculously inaccessible (one might even say hostile) to open source due to their pricing model based on number of subscribers.
• incident.io is a newish tool which has a "free forever" tier.

But there are several issues:

• There are too many platforms to choose from, leading to bikesheding (see: this issue).
• Ultimately, the implementation requires assessment and buy in from maintainers, which takes even more time.
• Implementing an entirely new channel just to replace the embed on the 500 error page seems like the wrong angle to come at the problem.
• A new dedicated channel will upset existing and expected outage workflows for both community users and maintainers.
• Setting the embed aside, it seems that most bases are covered with Mastodon and Slack, so introducing yet another channel adds noise — not to mention more busywork for Infra team to post updates across channels — unless steps are also taken to pull back from all the other platforms and centralize comms.

Reframing this problem from an end user perspective, when I see a 500 Error page the first thing I want to do is to be able to see if the incident is known, and if not know where to go to report it. I typically go to the https://x.com/drupal_infra first but only because that's where I'm directed to go. If I don't see anything reported there — it usually hasn't been — then I head over to #drupal-infrastructure channel on Drupal Slack to check for a report or discussion — it usually has been. From there, I can then finally see the link in the channel description to https://mastodon.social/@drupalinfra which might have different outage information than what is reported in Slack.

As an interim solution, could we just point to Mastodon and (optionally, the Drupal Slack channel) instead of Twitter/X on the 500 error page? Do we really even need to replace the embed on the 500 page?