honeybadger-debugging

name

honeybadger-debugging

description

Investigate and fix a specific Honeybadger exception in the Bike Index app — pull the fault, read its backtrace, find the offending code, write the fix. Trigger whenever a request names one Honeybadger error: a pasted fault URL (`app.honeybadger.io/projects/…/faults/…`), a fault ID, an error class plus "in production" (`Vips::Error`, `NoMethodError in AfterStolenRecordSaveJob`), or phrasings like "fix this Honeybadger error", "why is this erroring in prod", "what's causing this exception", "look at this HB fault". Use `bin/binx_hb` for fault and notice detail rather than the Honeybadger MCP, whose notice objects run ~3K tokens each. Not for a broad production health sweep across many sources, and not for reading raw log files (that's production-log-inspection).

Fixing a Honeybadger exception

Pull the fault with bin/binx_hb

Run it from the repo root — bin/binx_hb with no arguments prints its own usage. Two modes matter here: fault for the summary, notice for the backtrace.

bin/binx_hb fault  https://app.honeybadger.io/projects/35931/faults/133010748
bin/binx_hb notice backend/133010748

Both take a pasted fault URL or <project>/<fault_id>, where project is backend, frontend, or csp. Each prints raw: tmp/hb-…json on its last line — answer follow-up questions with jq against that file rather than fetching again.

It reads HONEYBADGER_PERSONAL_AUTH_TOKEN from .env.development. Without it the command exits saying so; fall back to the Honeybadger MCP's list_fault_notices through a subagent, so the payload stays out of the main context.

Why not the MCP directly: its notice objects carry backtrace and as byte-identical copies plus full environment blobs — ~3K tokens for a backtrace projects in ~700. The MCP is still right for aggregates (, ).