Overview
Set the purpose, scope, audience, and boundaries before the detailed chapters.
4.8
on G2
Free Downloadable Template
Symptom-indexed guide for diagnosing and fixing faults: causes, checks, resolutions, error codes, escalation. Download the editable blank, or create a draft from your recordings in Docsie.
Use this guide to identify a symptom, run the relevant checks, isolate a fault, and verify recovery. Keep symptom wording consistent between the index, fault records, and error-code reference so a technician can find the correct path quickly.
Complete the bracketed fields with approved information for the product, organization, or program being documented. Repeat the named forms where several tasks or subjects need separate records. Remove sections that do not apply and retain links to the material used to complete the document.
| Document control | Entry |
|---|---|
| Document identifier | [Identifier used by your team] |
| Scope and applicable version | [Product, program, locations, and version covered] |
| Prepared and maintained by | [Responsible role or team] |
| Revision and review | [Revision, review date, and approval reference] |
Identify the system and the reader's expected knowledge. Explain how to move from an observed symptom to the matching diagnostic record.
| Field | Complete with |
|---|---|
| System and scope | [Product, version, covered subsystems, and exclusions] |
| Audience | [Required qualifications, permitted tasks, and access prerequisites] |
| Using the guide | [How symptoms, codes, corrective procedures, and escalation records connect] |
| Sources | [Authoritative service or product information and its applicable revision] |
Describe only the system behavior needed to recognize an abnormal state. Keep normal values and diagram references close to the components they describe.
| Field | Complete with |
|---|---|
| Components | [Component, function, connection, and diagram reference] |
| Controls and indicators | [Exact label, possible states, and interpretation] |
| Normal conditions | [Expected value or behavior, units, operating condition, and source] |
| Dependencies | [External system, prerequisite state, and visible effect when unavailable] |
Record general precautions before diagnostic tasks and place a task-specific warning before the affected check. Define when work must stop or pass to a qualified role.
| Field | Complete with |
|---|---|
| Hazard | [Relevant hazard, consequence, diagnostic activity, and source] |
| Required control | [Isolation, protective measure, qualification, or backup requirement] |
| Stop condition | [Observed state requiring a stop or safe-state procedure] |
| Recovery or emergency | [Source-defined response, authorized role, and reference] |
Create one index entry for each diagnostic record. Use the exact same symptom or message wording in the index and the record title.
| Field | Complete with |
|---|---|
| Symptom wording | [Observable behavior, indicator, or exact message] |
| Affected area | [Subsystem, function, component, or operating mode] |
| Diagnostic record | [Record identifier and title for the matching investigation] |
| Related code | [Fault or error code and its reference entry when applicable] |
Document the checks that apply before detailed fault isolation. Distinguish confirming the reported symptom from the corrective work that follows diagnosis.
| Field | Complete with |
|---|---|
| Starting state | [System state, reported symptom, access, tools, and relevant precautions] |
| Basic checks | [Connections, dependencies, status, logs, or self-tests described by the source] |
| Observations | [Check result, expected condition, timestamp, and retained evidence] |
| Next decision | [Continue to a fault record, use a corrective procedure, stop, or escalate] |
Repeat this procedure for each supported task or variant. Place the applicable warning before the affected action and record a result that can be checked.
| Step | Action | Expected result | Evidence |
|---|---|---|---|
| 1 | [One action using the exact interface label or approved command] | [Observable state] | [Check or record] |
| 2 | [Next action in dependency order] | [Observable state] | [Check or record] |
| 3 | [Verification or handover action] | [Completion condition] | [Retained evidence] |
Repeat this fault record for each symptom and group records by subsystem or function. Follow the diagnostic sequence and preserve the result that leads to each next step.
| Field | Complete with |
|---|---|
| Fault record | [Identifier, exact symptom, affected area, conditions, and prerequisites] |
| Diagnostic path | [Check, expected result, observed result, supported cause, and next decision] |
| Resolution | [Corrective action or shared procedure reference and required authority] |
| Verification | [Check confirming restored operation, evidence, and condition requiring escalation] |
Keep code definitions distinct from the procedure used to investigate them. Record where the code appears and the evidence needed to interpret it.
| Field | Complete with |
|---|---|
| Code | [Exact code or range, displayed text, subsystem, and applicable version] |
| Meaning | [Documented condition and relevant operating context] |
| Investigation | [Matching symptom record, log fields, and diagnostic reference] |
| Response | [Supported action, reset condition if stated, and escalation reference] |
Create a shared corrective procedure when several diagnostic records use the same action. Keep prerequisite diagnosis and the expected recovered state explicit.
| Field | Complete with |
|---|---|
| Procedure | [Action, applicable faults, required authority, and reference] |
| Preparation | [Access, tools, isolation, backup, and relevant precautions] |
| Correction | [Ordered actions, exact settings or command references, and stop conditions] |
| Verification and record | [Functional check, observed result, changes made, and retained evidence] |
Repeat this procedure for each supported task or variant. Place the applicable warning before the affected action and record a result that can be checked.
| Step | Action | Expected result | Evidence |
|---|---|---|---|
| 1 | [One action using the exact interface label or approved command] | [Observable state] | [Check or record] |
| 2 | [Next action in dependency order] | [Observable state] | [Check or record] |
| 3 | [Verification or handover action] | [Completion condition] | [Retained evidence] |
Identify when the technician should stop local investigation and hand the issue over. Include enough redacted evidence for the next team to continue without repeating completed checks.
| Field | Complete with |
|---|---|
| Escalation trigger | [Condition, impact, unresolved diagnostic result, and applicable severity rule] |
| Destination | [Responsible support role or channel and required authority] |
| Evidence package | [System version, timestamps, identifiers, logs, checks performed, and outcomes] |
| Handover and closure | [Requested decision, next responsibility, communication, and final verification] |
Use question records for usage guidance that is not a fault. Link to a task or reference rather than repeating a full procedure in an answer.
| Field | Complete with |
|---|---|
| Question | [A recurring user question stated clearly] |
| Answer | [Source-supported explanation and its applicability] |
| Task or reference | [Procedure, setting, or concept that provides the detailed guidance] |
| Exceptions | [Variant, limitation, or condition that changes the answer] |
Define terms and abbreviations used by the diagnostic records. Keep names consistent with interface labels, logs, diagrams, and error messages.
| Field | Complete with |
|---|---|
| Term | [Exact term or abbreviation] |
| Meaning | [Definition within the covered system] |
| Source | [Product, service, or operating reference] |
| Usage | [Related term or distinction that helps interpret a symptom] |
8 Repeatable Chapter Patterns
Teams preparing a troubleshooting guide from existing source material. Repeat a procedure, checklist, or reference chapter where needed, and keep only the sections your source material supports.
Set the purpose, scope, audience, and boundaries before the detailed chapters.
Place the relevant hazards, precautions, and source warnings before the actions they affect.
Keep exact settings, field values, commands, and supporting references easy to look up.
Use repeatable checks for readiness, handover, or completion.
Connect an observable symptom to diagnostic checks, resolution, and verification.
Give each task its prerequisites, ordered actions, expected result, and verification.
Group recurring questions with clear, source-supported answers and useful references.
Define the terms and abbreviations used throughout the document.
Use this guide to identify a symptom, run the relevant checks, isolate a fault, and verify recovery. Keep symptom wording consistent between the index, fault records, and error-code reference so a technician can find the correct path quickly.
Complete the bracketed fields with approved information for the product, organization, or program being documented. Repeat the named forms where several tasks or subjects need separate records. Remove sections that do not apply and retain links to the material used to complete the document.
| Document control | Entry |
|---|---|
| Document identifier | [Identifier used by your team] |
| Scope and applicable version | [Product, program, locations, and version covered] |
| Prepared and maintained by | [Responsible role or team] |
| Revision and review | [Revision, review date, and approval reference] |
Identify the system and the reader's expected knowledge. Explain how to move from an observed symptom to the matching diagnostic record.
| Field | Complete with |
|---|---|
| System and scope | [Product, version, covered subsystems, and exclusions] |
| Audience | [Required qualifications, permitted tasks, and access prerequisites] |
| Using the guide | [How symptoms, codes, corrective procedures, and escalation records connect] |
| Sources | [Authoritative service or product information and its applicable revision] |
Describe only the system behavior needed to recognize an abnormal state. Keep normal values and diagram references close to the components they describe.
| Field | Complete with |
|---|---|
| Components | [Component, function, connection, and diagram reference] |
| Controls and indicators | [Exact label, possible states, and interpretation] |
| Normal conditions | [Expected value or behavior, units, operating condition, and source] |
| Dependencies | [External system, prerequisite state, and visible effect when unavailable] |
Record general precautions before diagnostic tasks and place a task-specific warning before the affected check. Define when work must stop or pass to a qualified role.
| Field | Complete with |
|---|---|
| Hazard | [Relevant hazard, consequence, diagnostic activity, and source] |
| Required control | [Isolation, protective measure, qualification, or backup requirement] |
| Stop condition | [Observed state requiring a stop or safe-state procedure] |
| Recovery or emergency | [Source-defined response, authorized role, and reference] |
Create one index entry for each diagnostic record. Use the exact same symptom or message wording in the index and the record title.
| Field | Complete with |
|---|---|
| Symptom wording | [Observable behavior, indicator, or exact message] |
| Affected area | [Subsystem, function, component, or operating mode] |
| Diagnostic record | [Record identifier and title for the matching investigation] |
| Related code | [Fault or error code and its reference entry when applicable] |
Document the checks that apply before detailed fault isolation. Distinguish confirming the reported symptom from the corrective work that follows diagnosis.
| Field | Complete with |
|---|---|
| Starting state | [System state, reported symptom, access, tools, and relevant precautions] |
| Basic checks | [Connections, dependencies, status, logs, or self-tests described by the source] |
| Observations | [Check result, expected condition, timestamp, and retained evidence] |
| Next decision | [Continue to a fault record, use a corrective procedure, stop, or escalate] |
Repeat this procedure for each supported task or variant. Place the applicable warning before the affected action and record a result that can be checked.
| Step | Action | Expected result | Evidence |
|---|---|---|---|
| 1 | [One action using the exact interface label or approved command] | [Observable state] | [Check or record] |
| 2 | [Next action in dependency order] | [Observable state] | [Check or record] |
| 3 | [Verification or handover action] | [Completion condition] | [Retained evidence] |
Repeat this fault record for each symptom and group records by subsystem or function. Follow the diagnostic sequence and preserve the result that leads to each next step.
| Field | Complete with |
|---|---|
| Fault record | [Identifier, exact symptom, affected area, conditions, and prerequisites] |
| Diagnostic path | [Check, expected result, observed result, supported cause, and next decision] |
| Resolution | [Corrective action or shared procedure reference and required authority] |
| Verification | [Check confirming restored operation, evidence, and condition requiring escalation] |
Keep code definitions distinct from the procedure used to investigate them. Record where the code appears and the evidence needed to interpret it.
| Field | Complete with |
|---|---|
| Code | [Exact code or range, displayed text, subsystem, and applicable version] |
| Meaning | [Documented condition and relevant operating context] |
| Investigation | [Matching symptom record, log fields, and diagnostic reference] |
| Response | [Supported action, reset condition if stated, and escalation reference] |
Create a shared corrective procedure when several diagnostic records use the same action. Keep prerequisite diagnosis and the expected recovered state explicit.
| Field | Complete with |
|---|---|
| Procedure | [Action, applicable faults, required authority, and reference] |
| Preparation | [Access, tools, isolation, backup, and relevant precautions] |
| Correction | [Ordered actions, exact settings or command references, and stop conditions] |
| Verification and record | [Functional check, observed result, changes made, and retained evidence] |
Repeat this procedure for each supported task or variant. Place the applicable warning before the affected action and record a result that can be checked.
| Step | Action | Expected result | Evidence |
|---|---|---|---|
| 1 | [One action using the exact interface label or approved command] | [Observable state] | [Check or record] |
| 2 | [Next action in dependency order] | [Observable state] | [Check or record] |
| 3 | [Verification or handover action] | [Completion condition] | [Retained evidence] |
Identify when the technician should stop local investigation and hand the issue over. Include enough redacted evidence for the next team to continue without repeating completed checks.
| Field | Complete with |
|---|---|
| Escalation trigger | [Condition, impact, unresolved diagnostic result, and applicable severity rule] |
| Destination | [Responsible support role or channel and required authority] |
| Evidence package | [System version, timestamps, identifiers, logs, checks performed, and outcomes] |
| Handover and closure | [Requested decision, next responsibility, communication, and final verification] |
Use question records for usage guidance that is not a fault. Link to a task or reference rather than repeating a full procedure in an answer.
| Field | Complete with |
|---|---|
| Question | [A recurring user question stated clearly] |
| Answer | [Source-supported explanation and its applicability] |
| Task or reference | [Procedure, setting, or concept that provides the detailed guidance] |
| Exceptions | [Variant, limitation, or condition that changes the answer] |
Define terms and abbreviations used by the diagnostic records. Keep names consistent with interface labels, logs, diagrams, and error messages.
| Field | Complete with |
|---|---|
| Term | [Exact term or abbreviation] |
| Meaning | [Definition within the covered system] |
| Source | [Product, service, or operating reference] |
| Usage | [Related term or distinction that helps interpret a symptom] |
Bring your recordings and select this template. Docsie organizes supported material into chapters and task articles for your team to review.
Downloads are editable blank templates. Review generated content against your source material before use.
Install, configure, secure, monitor, back up, and maintain a system as its administrator
Software architecture description in arc42 order: goals, context, views, decisions, quality, and risks
Developer portal with quickstart, authentication, concepts, how-to guides, endpoint reference, errors, and changelog.