As of 13 August 2026, AI can only partly analyse your application's error logs.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, chat-fluent skill, and roughly 30 minutes until you can act on the result.

   How to actually do it

   1. Open the relevant log viewer or exported log file and copy a narrow window around the incident, including timestamps, service names, request or trace IDs and the full error and stack trace where available.
   2. Remove passwords, API keys, access tokens, session cookies, personal data and other secrets, then replace each removed value with a clear label such as [REDACTED TOKEN].
   3. Gather the application version, environment, affected endpoint or job, expected behaviour, observed impact, recent deployments or configuration changes and any linked incident or request ID.
   4. Paste the context and redacted logs into a chatbot with the supplied prompt, asking it to distinguish observed facts from hypotheses and to list missing evidence.
   5. Open the relevant source code, deployment history and configuration in your normal engineering tools and compare them with each claimed error pattern and timeline.
   6. Run the proposed checks in a non-production environment first, or ask a colleague who knows the system to approve production checks, then record which hypothesis each result supports or rejects.
   7. Write the confirmed cause and next action in the incident record, and apply only the approved fix through your normal review, testing and deployment process.

   Prompt

   Analyse the application error logs below as an incident investigator. First separate directly observed facts from inferences. Then identify repeated error patterns, the earliest relevant event, likely contributing causes, and alternative explanations. Correlate timestamps, request or trace IDs, services, hosts, deployments and error messages where the data supports it. Do not invent missing context, credentials, configuration, commands, events or root causes. State what evidence would confirm or reject each hypothesis. Give safe, reversible investigation steps first, followed by remediation options that require human approval. Do not recommend destructive commands, secret exposure, disabling security controls or production changes without clearly marking the risk. Return: 1) concise incident summary, 2) evidence table, 3) ranked hypotheses with confidence described in words, 4) missing information, 5) verification plan, and 6) proposed next actions. Context: application [name], version [version], environment [development, staging or production], deployment or change [details], expected behaviour [details], observed impact [details]. Logs: [paste redacted logs here].

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.