Health and readiness
Read user-visible server setup, access, feature, and source status without exposing a platform operations runbook.
- Audience
- team lead · server admin
- Availability
- private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
Read health as an operator checklist
System Health combines user-visible status for the selected server: setup checks, configured destinations, Discord roles and channels, bot permissions and hierarchy, record counts, trusted sources, and feature access.
Select the server and failing group
The viewer needs the server's Health page permission. Sensitive setup repair, settings, teams, sources, and plan controls continue to enforce their own permissions.
Open System Health after initial setup, before enabling a new workflow, and whenever an administrator receives a repeatable permission, routing, or missing-surface report.
- The exact selected server and reported workflow.
- A recent timestamp, affected role, and visible error/status.
- Permission to open the related server settings only if repair is required.
Diagnose before attempting repair
Read group summaries
Start with Action needed, Review, or Ready groups and open the first failing detail.
Check: The administrator focuses on a concrete server-scoped prerequisite.
Compare live Discord state
Confirm referenced roles, channels, categories, forums, bot membership, permissions, and hierarchy.
Check: Stale stored identifiers are separated from current Discord objects.
Check feature and source state
Review access labels, feature availability, and external sources relevant to the report.
Check: Setup, feature access, and source health are not conflated.
Repair through the owning guide
Use Setup, Settings, Teams, Sources, or Plan only for the specific failed check, then refresh Health.
Check: The change is limited and readiness is re-evaluated.
Recheck the live Discord state
A server administrator can identify whether a user-visible failure comes from setup, Discord state, access mapping, feature availability, source configuration, or queued work and can follow the matching public repair path.
Read Ready, Review, and Action needed
| Status | Meaning | Operator response |
|---|---|---|
| Ready | The implemented checker found the current prerequisites it knows how to verify. | Run the representative workflow test; Ready is not production certification. |
| Review | The workflow may operate, but optional configuration, visibility, source, or feature state needs human inspection. | Read the detail and decide whether the warning affects the planned job. |
| Action needed | A required stored value, Discord object, permission, hierarchy rule, access gate, or supported dependency failed. | Follow the owning guide and repair the first concrete failure. |
| Unknown/unavailable | The checker could not obtain a current answer. | Do not treat unknown as healthy or unhealthy; verify live state and preserve the timestamp. |
Health groups to inspect
| Group | Examples | Owning guide |
|---|---|---|
| Access | Approved runtime, dashboard entry, selected-server membership, page permissions. | Server access and dashboard; Moderation teams and permissions. |
| Core configuration | Required role/channel IDs, log destinations, feature settings. | Settings and logging. |
| Discord objects | Role, category, channel, forum existence and resolved identity. | Initial setup and repair. |
| Bot capabilities | Permissions, role hierarchy, membership, send/read/manage ability. | Initial setup and repair. |
| Cases/review | Case, evidence, Ban Review, appeals destinations and permissions. | Cases and evidence; Ban Review; Appeals. |
| Sources and data | Configured external sources, native Activity status, visible counts and coverage. | Trusted sources; Imports; Activity. |
| Feature access | Plan inclusion, preview, production flag, private-beta state. | Understand your server's access; Feature status and availability. |
| Queued work | Supported scheduled or processing states exposed to administrators. | Scheduled Actions; Soundcheck artifacts. Backfill details remain reserved. |
Diagnose before repairing
Reproduce with a test action
Record the exact page/command, selected server, user role, target/record, time, and visible error without private content.
Check: The report is specific.
Open the first failing group
Start with Action needed before secondary warnings or counts.
Check: The root prerequisite is prioritized.
Compare live Discord state
Resolve the referenced object and inspect current permissions/hierarchy directly.
Check: Stale storage is distinguished from a live Discord problem.
Check access and feature state
Separate permission, plan, flag, approval, and maturity.
Check: A locked/disabled feature is not misdiagnosed as broken setup.
Use one owning repair
Change only the role, channel, setting, team mapping, or supported setup option tied to the failure.
Check: The repair changes only the failed item and can be reversed.
Refresh and retest
Re-run Health and one representative workflow.
Check: The status and actual behavior agree.
Prepare a health report
| Include | Exclude |
|---|---|
| Server name and numeric ID | Bot token, OAuth secret, session cookie, database path. |
| Health group, check label, status, and visible detail | Private evidence or full transcript content. |
| Page/command, user role/team, time, and last safe step | Unnecessary personal data or payment details. |
| Before/after object IDs or settings when safe | Provider credentials or private infrastructure topology. |
| One redacted screenshot only when it contains no sensitive data | Screenshots of hidden channels, evidence, or member private information. |
Escalate an unresolved health failure
Ready means the implemented checker found its current prerequisites; it is not paid-beta or broad-production certification. Some external availability can be temporarily unknown, and Health intentionally omits non-public platform procedures.
The server does not match the change you made
What you see: A control is unavailable, validation fails, or the resulting server state differs from the intended configuration.
What may be happening: Selected-server context, Discord permission, ModFlow team permission, feature access, stale Discord objects, or concurrent changes may block the workflow.
What to do
- Capture the failing group, check label, and detail without private data.
- Confirm the Discord object and effective role permission.
- Follow the owning server-scoped guide for one targeted repair.
- Escalate persistent unknown/unavailable state with the selected server and timestamp.
Check provider and release readiness
- Logging health covers destination validity, bot send permissions, queued delivery, retries, and recent failures; it does not prove every Discord event was observed.
- Provider-backed features require their own connection, credential, permission, quota, and revocation checks.
- MIRA additionally requires product, guild, legal, Premium, worker, budget, and source-visibility gates and remains coming soon.
- Canonical Case linkage and historical remediation must be verified in the deployed release; source code or a completed local test is not deployment proof.