This is not an error in our software, closing as invalid so as to not count as a production error.

As I understand it, errors from third-party domains are ignored by default on the mediawiki-client-errors dashboard, and team-specific dashboards for client errors are afaik generally based on this one.

The task description links to the Reading Web dashboard which I thought was based on mediawiki-errors (server-side PHP), but it seems to be an interesting mixture of multiple incompatible data sources.

While a single dashboard sounds appealing, I would recommend against it as most of OpenSearch's filter UI features will break when doing that, and most of the panels also look broken as a result. This is mainly due to involving i

Generally the way teams at Wikimedia use Logstash is that at the broadest it queries all from a single data source, and generally narrower than that. Including multiple data sources means there is data with incompatible schemas displayed, which means most shorthand and filter options don't work, such as easily selecting only PHP stack traces from core components and extensions that you maintain doesn't work since as soon as you do that, you lose all eventgate and mw-client messages which don't have a a PHP stacktrace field.

I'd recommend using the guide to set up dashboard for the team for MediaWiki PHP (based on the mediawiki-errors template), and another for JS (based on the meidawiki-clieint-errors template). It might also help with context switching and other conventions. E.g. server-side errors tend to be very low in numbers due to our CDN caching, and we tend to maintain zero tolerance there (apart from e.g. timeouts).

On the other hand, client-side errors tend to be amplified and need a minimum threshold to ignore the inevitable noise from uncontrolled browser extensions, console debugging, etc. Mixing these together probably confuses the operator which is which, and also means you're likely to miss server-side failures until they hit group2.