AI log analysis with your own API key

Pasting a stack trace into a chat window works, but it is slow and you pick the evidence by hand. ZipLogger can send the evidence it already has to a large language model and show the answer next to the error. It runs on your own AI account, with your own key.

This post covers how to set it up, what each AI feature does, what data leaves ZipLogger when it runs, and what it does not do.

Add your key

Go to Settings → Integrations and find the AI analysis card. You need the Admin role to save a key.

1. Pick a provider: Claude (Anthropic), GPT (OpenAI) or Gemini (Google).
2. Paste the API key from that provider's console.
3. Optionally type a model id. Leave it empty to use the default: claude-sonnet-5, gpt-5-mini or gemini-2.5-flash.
4. Click Save key.

Before the key is stored, ZipLogger makes one tiny real request with it ("Reply with the single word OK."). If the provider rejects the key or the model name, you get an error and nothing is saved. A key that passes is stored encrypted and is never shown again. Replace key swaps it, Remove turns every AI feature off.

AI analysis is part of the Pro, Team and Business plans. The Free plan does not include it. Each plan has a monthly number of AI requests; the figures are on the pricing page.

Your provider bills you for the tokens, as it would for any other use of your key. ZipLogger does not add a charge on top of calls made with your key.

What it does

There are five places the model is used. Two you trigger from the Search page, one from a regression case, one from an incident, and one runs on its own when a browser check fails.

Ask in plain English

On the Search page, the box above the results says Ask in plain English, e.g. "payment errors in the last hour". Type a question and click Ask.

Only the text you typed is sent. The model is asked to return three things: keywords to match in the message, a severity (debug, info, warn, error or fatal, or empty for any), and how many hours back to look. ZipLogger clamps the hours to between 1 and 720, fills in the search and runs it. The search itself is an ordinary ZipLogger search. The model never sees your logs in this step.

If the answer can't be read as that JSON, you get "The AI could not turn that into a query" and nothing runs.

Summarize errors

Next to Ask is Summarize errors. It reads the error-level logs in the time range you have selected, up to 3,000 lines, and groups them into patterns with the same clustering the Patterns view uses. It then sends the 15 biggest patterns and their counts. Not the raw lines.

The clustering replaces numbers, hex values, UUIDs and IPv4 addresses with <*>. For a test batch of 286 error lines, ZipLogger's clustering code produced exactly this message for the model:

Top error patterns in the last window (286 error events analyzed):
- [212x] Payment provider timeout after <*> ms for order <*>
- [64x] Npgsql.NpgsqlException: connection to <*> refused
- [9x] Unhandled exception in GET <*> NullReferenceException
- [1x] Could not load pricing rules for region eu-west

The instructions ask for about 150 words on the most impactful issues, likely causes and next steps, and say not to invent details the data does not support. The summary shows under the search box. It is not saved.

Two things to know. The summary uses the time range only, not your search text or other filters, so it covers every error in that range. And it reads severity error exactly, so fatal lines are left out. The log pattern clustering post explains how the grouping works and where it goes wrong.

Root cause for a regression

When ZipLogger ties an error to a suspect commit, the regression case shows Ask AI: root cause & suggested fix. How the suspect commit is found is covered in Find the commit that broke production, so here is only the AI part.

The model gets the error message, the stack trace, the suspect commit's short sha, author and message, and its diff. The diff is cut at 6,000 characters. The answer comes back in two parts, ROOT CAUSE and SUGGESTED FIX, and is saved on the case so the next person reads the same one. If a key is saved when the case is first created, this runs straight away without the click.

Explain an incident

On an incident's page, the AI analysis card has Explain this incident (or Analyse again once there is an answer). Editors and Admins can run it.

This one sends the most. The prompt holds the incident's title, severity, status, service, environment and description (up to 1,200 characters), the figures shown on the page (log and error counts against the window before, request counts and p95 latency, browser check results, health check state, recent releases and regression cases), the last 25 timeline entries, and up to 12 error logs from that service in the window. Each log message is cut at 300 characters and its stack trace at 500.

The answer is stored on the incident and a line is added to the timeline, so the whole team reads one analysis.

Explain a failed browser check

Browser automations have a checkbox, Explain failures with AI, which is on by default. When a run fails and opens an incident, ZipLogger sends the monitor name and start URL, each step with its result and error, page timing, up to 8 console errors, up to 10 failed requests (method, URL and status), the server-side error if your backend's trace for that run recorded one, and up to 10 commits since the journey last passed. The model is asked for the most likely cause in 120 words or fewer. There is more on the checks themselves in the browser monitoring post.

What is sent, and what is not

The request goes from ZipLogger's server straight to your provider's API (api.anthropic.com, api.openai.com or generativelanguage.googleapis.com) with your key. Your provider's data policy for API traffic applies to it.

To be precise about redaction: ZipLogger does not run a separate scrubbing step before it calls the model. What limits the data is how each prompt is built:

• Ask sends only your question.
• Summarize sends pattern templates and counts, with the variable parts listed above replaced by <*>. An email address or a name inside a message is not replaced.
• The regression, incident and browser-check prompts send text as ZipLogger stored it, cut to the lengths above.

So the rule for AI is the same as for logging in general. Keep passwords, tokens and personal data out of your log messages in the first place.

Nothing is sent when no key is saved. Without a key, Ask and Summarize errors are disabled, the incident and regression buttons answer with a pointer to the settings, and every other feature works as usual.

How it is counted

Each AI operation counts as one AI request against your plan's monthly number. Ask and Summarize errors count one per click. A regression analysis, an incident analysis and a browser-check explanation count one when an answer comes back. The test call made when you save a key does not count.

When the month's AI requests are used up, the buttons answer "Monthly AI request quota exhausted for the current plan." The automatic ones (a new regression case, a failed browser check) are skipped without an error. Analyse again on an incident, or asking again on a regression case, is a new request, both on your plan and on your provider's bill.

What it does not do

• It is not a chat. Each click is one request with one prompt. You can't ask a follow-up.
• It only sees what is in the prompt. It can't open your code, read logs outside the sample, or query anything else.
• It can be wrong. The prompts ask the model to say when the evidence is thin, but read the answer as a lead to check, not a finding.
• Summaries are of a sample. Up to 3,000 error lines, 15 patterns. On a busy service that is a ranking, not a census.
• One key per workspace. There is no per-team or per-feature provider choice.

If you want an assistant that can look at your code and your logs together, the MCP post shows how to connect Claude Code or Cursor instead.

The setup is also in the AI analysis docs. If you don't have a workspace yet, sign up, then add your key under Settings → Integrations.