Troubleshooting

Capture the symptom

Record the time, visible error, chosen model, and the steps that led to the failure. Do not include credentials, session data, or private source contents.

Reduce the task

Try a short prompt without attachments. Add one source at a time to find whether the failure follows a file, a model, or a service.

Check before restarting

Inspect the relevant status and approved diagnostics. Preserve evidence and avoid restarting services or altering stored data as a first response.

Verify the repair

Repeat the original failing workflow and confirm that adjacent work remains intact. Use the help guide for a focused checklist.

Use Friday as a diagnostic guide

If conversation still works, describe the failure and ask Friday for a read-only checklist. If sign-in or chat is unavailable, use this website’s help guides and contact the operator. Do not rely on the failing service as your only source of recovery instructions.

Ask Friday to guide you

In an authorized FridayLocalAI conversation, try:

Help diagnose this FridayLocalAI issue: [sanitized error and steps]. First ask what still works. Suggest one low-impact check at a time and explain the expected result. Do not restart services, delete data, or change permissions.

Tell Friday what you can see and which step you have reached. If the instructions do not match your screen, say so; ask for the relevant Help topic or contact your operator. Friday cannot be assumed to see your screen or know your current settings.

Describe the observable failure

Begin with what you can see, not a theory about the cause. “The response stopped before completion” is an observation. “The model is broken” is a hypothesis. Useful details include the feature, time, steps, visible error, and the result you expected. State whether the issue happens every time or only with a particular input. Also record what still works. If sign-in and conversation history load but one attachment fails, that narrows the problem. If no conversation can respond, the investigation begins elsewhere. This distinction helps the operator choose a relevant check and prevents a broad explanation from obscuring the actual failing stage. Keep the report focused enough that someone else can understand the event without your entire workspace history.

Separate access from response generation

A sign-in problem, an unavailable page, and a failed model response are different conditions. If you cannot access the application, use the website guides or operator support. Do not depend on a conversation inside the inaccessible application to tell you how to recover it. If you can open the workspace, inspect the visible state before changing anything. For a response problem, try one small, harmless text prompt if doing so is appropriate. Note whether it completes and which active model attribution is shown. A successful simple prompt can help distinguish a general service issue from a source- or task-specific problem. It does not prove all features are healthy, but it provides a useful comparison with the original failure.

Reduce the example without losing the symptom

Remove unrelated complexity from the task. Use a shorter prompt, one source instead of several, or a small text sample instead of a complex document when possible. Change one relevant variable at a time so you can tell whether the symptom follows the input, selected context, or available capability. Do not simplify away the very condition you need to investigate. If the failure occurs only with a particular type of source, record that fact even if a plain-text example succeeds. If a workflow may already have produced an artifact or external result, check before retrying to avoid duplication. A minimal reproduction should make the issue clearer while respecting the state left by the original attempt.

Distinguish incorrect answers from execution errors

A completed response with inaccurate content calls for a different review from an error that prevented a response. For an inaccurate answer, inspect the prompt, source access, assumptions, and factual support. For a failed operation, inspect the visible status and the relevant service or capability through approved controls. Do not assume the same remedy applies to both. Ask Friday to explain possible causes if conversation is functioning, but keep those explanations labeled as possibilities until evidence supports them. A plausible diagnosis can guide the next check; it is not proof. Preserve the original symptom and the result of each relevant check so the operator can understand how the investigation progressed instead of receiving only the final guess.

Make changes through the appropriate operator

Service restarts, database changes, storage repairs, and permission changes can affect more than the current conversation. They should follow the deployment’s authorized operating process. Do not copy a generated command into an important environment merely because it appears precise or promises a quick fix. When a change is approved, identify the target, expected effect, verification step, and recovery path. Keep changes focused so their impact can be understood. Afterward, repeat the original failing workflow and inspect the outcome. A different successful prompt is not sufficient evidence that the initial issue was fixed. Also check any adjacent behavior that the change could reasonably affect without expanding the investigation into unrelated systems.

Prepare a report that supports action

A useful report includes a short title, the environment or feature, reproduction steps, expected and actual behavior, and the relevant time or request identifier if visible. Include Agent and model attribution when it helps explain a response. Redact credentials, session information, and private source contents. If sensitive evidence is needed, agree on an appropriate channel with the operator. Friday can help turn observations into that structure when chat remains available. Ask it to preserve uncertainty and avoid inventing technical details. You review and send the report through the intended route. The goal is to provide enough information for a targeted investigation while avoiding unnecessary disclosure or disruptive trial-and-error changes. Clear evidence and a controlled verification step are more useful than a long list of speculative fixes.