Site health dashboard
From Mattermost v12.2, the Site health dashboard gives system administrators a single view of active health findings across their Mattermost deployment.
Access the dashboard
Go to System Console > Reporting > Site health. Only system administrators can access this page.
What the dashboard checks
The dashboard runs built-in checks against your configuration and the live state of your deployment. Checks are grouped into the following categories:
| Category | Examples of what is checked |
|---|---|
| Platform | Site URL is set and uses HTTPS, file storage is reachable, plugin health checks and plugins that fail to run, whether file logging is enabled, rate limiting memory store size, file descriptor usage, and the host operating system. |
| Database | Connection pool sizing and saturation, read and search replicas, query timeout, SQL tracing, and the PostgreSQL version. |
| Search | Search availability, Elasticsearch or OpenSearch version and plugins, connection security, indexing batch size, and whether your post volume calls for Elasticsearch. |
| Cluster | High availability nodes that can't reach each other, a cluster running with a single node, mixed Mattermost versions across nodes, unencrypted cluster traffic, and the cache backend at scale. |
| Authentication | LDAP and SAML connectivity and security settings, LDAP sync configuration, session length settings, and whether single sign-on is set up at scale. |
| Notifications | Push notification server address and security, push notification contents, SMTP connectivity, and channel-wide mentions in large channels. |
| Compliance | Audit logging, the compliance export directory, and data retention and Global Relay export settings. |
| Jobs | Background jobs that failed, are stuck in progress, or have made no progress. |
| Licensing | Whether your license has expired or expires soon, and whether licensed seats are nearly full, reached, or exceeded. |
| Version | Whether your Mattermost version is past end of life, an Extended Support Release is nearing end of life, or newer releases are available. |
Understanding findings
The dashboard evaluates your deployment and surfaces findings in one of three states:
| State | Meaning |
|---|---|
| Firing | The check is failing and requires attention. |
| Unknown | The check cannot run and its result is indeterminate. |
| Resolved | The check was previously failing and has since passed. |
Each finding row shows its severity, title, category area, and how long the condition has been in its current state. Select a row to expand it and read the full description and any remediation guidance.
Severity levels
| Severity | Meaning | What to do |
|---|---|---|
| Critical | A core capability is broken or at imminent risk, such as an unsupported Mattermost version, search being unavailable, or the database connection pool being nearly exhausted. | Fix as soon as possible. |
| Warning | A misconfiguration or risk that degrades security, reliability, or performance but isn't causing an outage today. | Plan a fix. |
| Info | A recommendation or best practice for your deployment's size and setup. | Review and decide whether it applies to you. |
How checks run
Checks run automatically about once an hour. In a high availability cluster, one node runs the checks on behalf of the whole cluster.
- After the feature is enabled, the first check runs within an hour. Until then, the dashboard has no findings to show.
- After you fix the cause of a finding, it moves to Recently resolved after the next check run, which can take up to an hour.
- A finding becomes Unknown when the information needed to evaluate it isn't available, for example because a service the check depends on can't be reached, or because the check hasn't reported for longer than expected.
Filter by tab
Findings are grouped into tabs:
- Open — all firing and unknown findings.
- Critical, Warning, Info — firing findings filtered by severity.
- Recently resolved — findings that have cleared.
- Unknown — checks that could not run.
Tab counts reflect only unmuted findings. If every finding in a tab is muted, the tab displays how many findings are muted rather than an all-clear message, so muting a critical finding never makes the page appear healthy.
Group by
Use the Group by control to switch between grouping findings by Severity (the default) or Category.
Muting findings
Muting suppresses a finding from the open list without stopping the underlying check. The check continues to run; the finding is simply hidden from the tab views. Use muting for known conditions you are tracking separately or have accepted as a temporary state.
Mutes are workspace-wide: a finding muted by one administrator is muted for all administrators.
Mute a finding
Firing and unknown findings have a Mute button at the right end of the row. Select Mute to suppress the finding immediately. No confirmation dialog appears — unmuting is one click away in the Muted list.
Resolved findings cannot be muted.
View muted findings
A Muted button with a bell-off icon and the current muted count sits to the right of the filter tabs. It is always visible, including when the count is zero. Select it to open the muted findings list.
While the muted list is open, no tab is selected. The Group by control still applies, so you can view muted findings grouped by severity or category.
Each muted finding row shows:
- Who muted it.
- When it was muted (relative time, shown as "just now" for the first minute).
- An Unmute button.
Unmute a finding
Select Unmute on any row in the muted list. The finding leaves the muted list and appears again in the tab for its current state, for example Recently resolved if the check has passed since you muted it.
Check health from the command line
Use the mmctl health check command to list the same findings shown on the dashboard. This is useful for scripting and for checking a server without opening the System Console.
mmctl health check
By default, only firing and unknown findings are shown. Use the following flags to include more:
| Flag | Description |
|---|---|
--include-resolved | Include resolved findings. |
--include-muted | Include muted findings. |
--packet <file> | Evaluate a Support Packet zip file on your own machine instead of querying a server. No server connection is needed, and findings intended for support engineers are also included. Can't be combined with --include-muted, because findings from a Support Packet are never muted. |
Add --json for machine-readable output.
Findings from --packet describe the server at the time the Support Packet was generated, not its current state.