Troubleshooting Pages
Overview
Use a troubleshooting page when the reader starts from a symptom and needs to diagnose and resolve a problem from evidence.
Organize the page by symptom, not by subsystem alone.
The primary reader question is: "Given this symptom, how do I confirm the cause, fix it, and verify recovery?"
Use This Page Type When
- the reader has a failure, timeout, deserialization problem, or runtime symptom
- the page can provide real evidence patterns, not speculative guesses
- the page needs confirmation steps and fix verification
Required Structure
- one-sentence symptom statement
## Symptoms## What this usually means## Probable causes## How to confirm## Resolution## Verify the fix## Prevention## Summary## Next Steps
Content Rules
- Use real error messages, metrics, or log signatures when available.
- Do not fabricate stack traces.
- Do not list speculative causes unless you also explain how to confirm or rule them out.
- State whether the fix is safe live and whether restart, rollout, or state repair is required.
Minimal Frontmatter Example
---
title: State Deserialization Fails After Upgrade
description: Diagnose and resolve Mississippi state deserialization failures after an upgrade using evidence, compatibility checks, and repair guidance.
sidebar_position: 70
sidebar_label: Deserialization Failures
---
Page Skeleton Example
# State Deserialization Fails After Upgrade
Use this guide when Mississippi fails to load persisted state after a version change.
## Symptoms
## What this usually means
## Probable causes
## How to confirm
## Resolution
## Verify the fix
## Prevention
## Summary
## Next Steps
Summary
- troubleshooting pages start from observable symptoms, not subsystem tours
- they should pair each probable cause with confirmation steps and concrete resolution guidance
- speculative causes without a confirmation path do not belong in this page type