This is intentional. The way it is meant to work is that uncaught errors or errors that otherwise means the request/process did not succeed in what it wanted to do (i.e. relevant operationally in terms of service health), that those go to the error channel.

Diagnostic messages of interest to the maintainers, or when looking for early signs or secondary fallout, are logged to individual components. These have access to a range of levels like (we generally use only debug, info, warning, and error) but are all confined to something that isn't relevant at the high level.

If a component is logging a fatal error to a diagnostic channel, that is a bug with that component.

The alternative suggested, which is to query diagnostic message from any channel that may locally use the "error" level, would most mean the signal can no longer be used operationally. E.g. it would no longer be a reliable signal for alerts (https://grafana.wikimedia.org/d/000000438/mediawiki-exceptions-alerts) or for Scap to validate deployments.

Perhaps we could change only the dashboard, and leave the alert and scap signal unchanged. But, then the dashboard would no longer be useful when responding to alerts, aborted deploys, or doing train triage.

In terms of when you're looking for other messages, we have other Logstash dashboards:

1. Logstash: mediawiki, any channel, any level.
2. Logstash: mediawiki-warnings, any channel, ignore debug/info level.
3. Logstash: mediawiki-errors, only the "error" channel (PHP errors and fatal MediaWiki exceptions).

So if you're intententionally looking for diagnostic messages the first two woud make a better starting point.