analyzer-timeout-analysis

Diagnose analyzer timeouts by correlating database records with GCP pod logs into an HTML dashboard.

Updated Jul 17, 2026
One-click install
npx skills add https://github.com/unnxt30/skills --skill analyzer-timeout-analysis-unnxt30
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: analyzer-timeout-analysis
Source: https://github.com/unnxt30/skills/tree/main/analyzer-timeout-analysis
Command: npx skills add https://github.com/unnxt30/skills --skill analyzer-timeout-analysis-unnxt30

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? When checks on a DeepSource-style analysis platform time out, the database stores no error payload because the watchdog kills the pod before it reports, leaving engineers blind to root causes. This Skill recovers the missing evidence by pulling raw analyzer pod logs and backend timeout verdicts from GCP Cloud Logging, classifying each failure, and presenting everything in an interactive local dashboard. ## Core Features & Use Cases - End-to-end timeout investigation: Queries the analysis-DB read replica via the mb CLI, fetches pod logs and watchdog verdicts via gcloud logging read, and classifies root causes such as clone failures, lost results, OOM kills, slow scans, and infra overhead. - Interactive HTML dashboard: Generates a self-contained index.html with daily trend charts, root-cause and repository filters, search, per-check lifecycle timelines, and links to raw logs and DB payloads. - Use Case: Ask why the secrets analyzer timed out between July and September; the Skill produces a dashboard showing that most failures were clone failures on deleted branches rather than slow scans, letting you route fixes to the right team. ## Quick Start Ask the AI to analyze why the secrets analyzer timed out between 2026-07-01 and 2026-09-01 and generate the timeout dashboard in a local output directory.

Frequently Asked Questions about analyzer-timeout-analysis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate analyzer timeouts on a DeepSource-style platform?

Run the analyze_timeouts.py script with the analyzer shortcode and a date window. It queries the analysis-DB read replica for timed-out checks, fetches raw pod logs from GCP Cloud Logging, classifies root causes, and writes an interactive HTML dashboard plus per-check log files.

Why does the database show no error for timed-out checks?

The timeout watchdog kills the analyzer pod before it can report, so check.errors, run.error_meta, and extra_data are all empty for timo statuses. Raw pod logs in GCP Cloud Logging are the only source of truth for what actually happened.

What tools and permissions does timeout analysis require?

You need the mb CLI with an authenticated profile, gcloud with an account that has Cloud Logging read access, python3, and a filled-in .env file specifying the GCP project, Metabase database id, namespaces, and container names.

Can I analyze check failures other than timeouts?

Yes, the --status flag accepts any check status, such as fail, with timo as the default. You can also use --skip-raw-logs or --skip-verdicts for a faster database-only analysis.

Why can a pod log show a successful scan for a timed-out check?

The timo verdict is assigned by a separate watchdog worker, not the analyzer pod. A scan can finish and publish its result, but if the result is lost in delivery or arrives after the deadline, the check is still marked timed out.

What root causes does the timeout classifier detect?

The classifier detects clone failures, lost or late results, slow scans, infra overhead, /results permission bugs, publish failures, stuck handoffs, OOM kills, and pods that were never scheduled. It is heuristic, so spot-check raw logs before presenting conclusions.