Request-log troubleshooting

Every authenticated request leaves a log

Request logs record chat traffic, routing decisions, cache and memory states, and outcomes for your workspace. They are the first place to look when a request behaves unexpectedly.

Listing and filtering

GET /v1/request-logs supports filters: limit (1–200, default 50), offset, event_type, status, route, provider, model, request_id, message, cache_state, memory_state, and from/to time range.

curl "https://api.hardcarrx.com/v1/request-logs?status=error&limit=50" \
  -H "Authorization: Bearer ***"

One request, full detail

Each log entry carries a request_id. Use it to pull the detail view for that exact exchange.

curl https://api.hardcarrx.com/v1/request-logs/<request_id> \
  -H "Authorization: Bearer ***"

Common signals

  • status_class — success vs error; start here when a request failed.
  • cache_state — miss/hit; unexpected misses explain latency or token-cost surprises.
  • memory_state — whether memory writeback ran or was skipped for the exchange.
  • provider / model — confirms which runtime identity actually served the request, useful when model naming is in play.

Typical debugging flow

  1. Filter recent logs by status=error and your route.
  2. Match the failing request by timestamp/model/request_id.
  3. Open the detail view to see the recorded outcome, then cross- check the error catalog for the retry decision.