Diagnose a Failed Response

Record what happened

Capture the exact visible error, time, selected model, and steps. Keep secrets and private source contents out of support notes.

Check availability

Review application and model-service status without restarting services. Distinguish a sign-in problem from a failed model request.

Reduce the inputs

Try a short prompt without attachments, then add one file at a time. Observe whether the failure follows the input, selected model, or service.

Escalate with context

Use the approved support route with a concise reproduction. Preserve diagnostic evidence and do not modify stored data to make an error disappear.

Know when to stop retrying

First distinguish an incomplete response from a completed but incorrect answer. Note whether the message was saved and whether an artifact or tool action was already produced before retrying. If chat itself will not respond, capture the visible error and use the contact page instead.

Ask Friday to guide you

In an authorized FridayLocalAI conversation, try:

Help me investigate a failed FridayLocalAI response using this sanitized description: [details]. Ask about the visible status and whether anything was saved or produced. Suggest one safe check at a time and help me prepare a support report if needed.

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.

Classify what happened

Before retrying, decide whether you saw no response, a partial response, a visible error, or a completed answer that did not meet the request. Those outcomes suggest different questions. Note whether your user message appears in the conversation and whether anything else was produced. A task involving an artifact or an external action may have progressed farther than the final text suggests. Record the time and the smallest set of steps that led to the problem. If an error message is visible, preserve its wording without including secrets or unrelated private content. Do not replace the observation with a diagnosis such as “out of memory” unless the available evidence actually establishes that cause. A precise symptom gives the operator a better starting point.

Check the selected context

Confirm the intended project, conversation, Agent, and Model controls. If a reply was produced, inspect its active attribution rather than relying only on the requested selection. A conversation opened through search may not be the one you expected, and changed context can affect what the task receives. If the issue concerns a source, confirm which file or excerpt was meant to be used. A filename displayed in the interface does not establish that the relevant contents reached the task. Ask a narrow source question if conversation is working. If it cannot answer from the source, investigate availability before treating the result as a model’s failure to understand material it may never have received.

Try a bounded comparison

When appropriate, send one short, non-sensitive prompt without attachments. For example, ask for a three-item checklist based on a sentence you provide. Observe whether it completes. If it does, add one relevant input back to the task and compare the result. This can help identify whether the problem follows an attachment, a more complex request, or a particular workflow. Keep the comparison deliberate. Repeatedly sending the same long request can create more confusion without producing new evidence. If an operation might have already changed state, inspect the result before repeating it. The goal is to learn which condition matters, not to generate enough attempts that one happens to look successful while the underlying problem remains unknown.

Handle a wrong answer differently

If the reply completed but contains an error, identify the unsupported statement and compare it with the supplied material. Give a specific correction and ask for a revised answer. If the task was ambiguous, clarify the goal or missing fact. If the answer claimed an action occurred, inspect the corresponding state or artifact before accepting that claim. A poor response can come from unclear instructions, missing context, unsuitable capability, or an error in generation. Changing models may be one possible evaluation step, but it should not be the automatic response to every issue. First ask what evidence would distinguish those explanations. This keeps the investigation tied to the actual task instead of a vague search for a more impressive answer.

Escalate when the next step is operational

If the application, model service, storage workflow, or permission boundary needs investigation beyond the controls available to you, contact the operator. Do not alter system settings or restart services simply to see whether the symptom disappears. Preserve the current evidence and describe what you tried, including checks that succeeded. If chat is unavailable, use this website’s guidance or the downloaded consumer documents to prepare the report. The assistant cannot be your only recovery path when the assistant itself is not responding. If the issue involves unrelated data becoming visible or an unexpected external action, stop the affected workflow and report the observation promptly without spreading the contents further.

Verify recovery using the original task

After an authorized repair or configuration correction, repeat a small version of the original failing workflow. Confirm the expected response, source use, saved state, or artifact. A generic “hello” response does not prove a document-processing issue is fixed. Match the verification to the symptom that led to the investigation. Record what passed and what remains uncertain. If the failure cannot be reproduced, say that rather than declaring the cause known. Keep a concise note of the outcome with the support exchange. Friday can help organize the observations, but the result you inspect is the evidence. A careful recovery leaves you with a clearer understanding of the workflow and a reliable next step if the same symptom returns.

A useful final check

Keep the original prompt and a sanitized account of the failure available for the operator. That makes it easier to compare the repaired workflow with the original symptom.