autumn-investigate

List billing calls and invoice webhooks around the charge time filtered by customer_id, then compare response_body invoice ids across repeated billing.attach requests. Multiple invoice.paid webhooks with different invoice ids indicate separate charges that each need tracing.

Query request logs for records where response_body.allowed is false for the customer, then read balance.remaining, next_reset_at, and breakdown on the denial. Walk backwards through track calls to find the usage that drained the balance.

searchRequestLogs returns full request records with payloads and is capped at 7 days per call, while queryRequestLogs returns aggregate rows via summarize and is capped at 30 days when filtering by customer_id. Always pass an explicit range since search defaults to only 30 minutes.

Logs can show that balances did not reset by comparing remaining and next_reset_at across checks straddling the boundary, but resets are internal processing. The logs show the effect, not the cause, so confirmed cases should be escalated to Autumn support.

Filter logs by source equal to stripe_webhook and the customer_id, then check status_code: 200 means processed, 400 or above means Autumn received but failed to process it, and no record means Stripe never delivered it. Each outcome has a different owner for the fix.

The pipeline syntax supports only where, summarize, project, order by, and limit stages with a fixed field list, and there is no full-text search. Payload access is limited to dot paths under request_body and response_body with at most four segments.