System Status Triage

System Status Triage (tiger-claw-v4-core)

A yellow or red signal is a CLAIM, not a diagnosis. The dashboard depends on the same infra it monitors, and most of its alarms are freshness / absence-of-activity heuristics, not proof of an outage. Establish ground truth read-only, classify the alarm, report.

No conclusion without ground truth. No ground truth = mark it UNVERIFIED. Don't guess, don't assume, don't pattern-match to a plausible shape.

Iron rules (each closes a real failure)

1. Read-only until proven. No edits, deploys, or config changes during triage — you don't yet know what's actually broken.
2. Ground every claim in a live probe (curl output) or a file:line with a quoted snippet. Never from memory.
3. Mark UNVERIFIED anything unreachable from this machine (live minutesSinceLast, secret values, per-instance state, DB rows). Most triage stations have no gcloud and no ADMIN_TOKEN — say so; never invent access (don't assume an MCP or token you haven't confirmed).
4. Classify before concluding: true outage, freshness/absence alarm, or incident-card noise. Never summarize a freshness alarm as "broken infrastructure."
5. Report, don't fix. Triage ends in a verdict + the one real anomaly (if any) + the UNVERIFIED list. Fixing is a separate, approved step.

Process

0. External read-only probes first (no repo needed):

curl -s -m 15 "https://api.tigerclaw.io/health"            # expect 200 + checks all ok
curl -s -o /dev/null -w "%{http_code}\n" "https://wizard.tigerclaw.io"   # front door
curl -s -o /dev/null -w "%{http_code}\n" -X POST -H "Content-Type: application/json" \
  -d '{}' "https://api.tigerclaw.io/webhooks/stripe"        # unsigned guardrail → expect 400
curl -s -w "\nHTTP %{http_code}\n" -X POST -H "Content-Type: application/json" \
  -d '{}' "https://api.tigerclaw.io/webhooks/stripe/commerce"   # expect 400 (or 503 if secret missing)

A 400 to an unsigned webhook probe is the healthy state — it proves the endpoint is up and signature-checking. It is NOT the alarm.

1. Locate the exact alarm code. Clone read-only (gh repo clone bbrysonelite-max/tiger-claw-v4-core /tmp/...) and find what computes it. Grep the symbol, not the line number (lines drift) — see the table.

2. Classify the alarm; state which of the three it is.

3. Whole-system read-only audit — dispatch parallel Explore subagents (they cannot write), one per subsystem, each required to cite file:line + quoted code and to label anything needing live access UNVERIFIED. Typical split: (a) the alarm's own pipeline, (b) Stripe/webhooks, (c) dashboard dependency + incident computation, (d) the affected feature's data capture.

4. Separate incident-card noise from real failures (scanner paths, stale session tokens) using classifyActiveIncident — quote the classification.

5. Report: verdict (GO / DEGRADED / DOWN), the single genuine anomaly if one exists, and an explicit UNVERIFIED list naming what needs gcloud / ADMIN_TOKEN / DB.

What each alarm actually measures

Verified against tiger-claw-v4-core main (grep the symbol; line numbers drift).

Tiger gotchas (the non-obvious truths)

• Webhook counters are in-memory, per Cloud Run instance (webhook_counters.ts). The dashboard may query a different instance than Stripe delivers to → false red. Not fleet-wide.
• A wrong webhook secret records as a failure but still updates lastEventAt → keeps the banner green. A green Stripe card does NOT prove provisioning works.
• The commerce webhook (/stripe/commerce) never increments the counter — invisible to the "Stripe webhook" card; it has its own provider_events table.
• Fire-test qualified_movement IS emitted in production every turn (runtime/movementPayload.ts, both Telegram + LINE) — a missing one means not correlated (chat_id mismatch) or aged out, not "never written."
• lead.started_bot is Telegram-only (services/tiger_card.ts, on /start Tiger Card claim). LINE has no equivalent.
• Booking metadata mismatch (LINE booked FAIL): source_channel / source_chat_id / tenant_id embedded by tools/tiger_book_zoom.ts and stored by services/calcom_webhooks.ts must match conversation_turns.chat_id — LINE userId encoding can differ between the two paths.
• Scanner rows (/.env, /phpinfo.php, stale MISSING_SESSION_TOKEN) enter Active Incidents legitimately — preserve as evidence, don't panic, don't let them bury a real row.

Without gcloud, ADMIN_TOKEN, or DB/cloud-sql-proxy you CANNOT verify the live minutesSinceLast, whether the Stripe secret matches, per-instance state, or a receipt's exact missing[]. Say UNVERIFIED and name what would confirm it.

Common mistakes