Traffic history

When an application calls many external APIs, there is usually no consistent record of what was actually sent and received. The moment a call fails or returns something unexpected, you are left reconstructing it from scattered logs, or guessing. Because HARP sits on the path between your application and the APIs it calls, it records the requests and responses passing through it, with no change to application code.

What HARP records

The traffic history is on by default. It records the transactions passing through the proxy, the HTTP request and its response, whether or not the call was forwarded to a remote backend. Storage happens asynchronously, off the critical path. Bodies are recorded up to 1 MiB each by default.

Recorded transactions stay available until the Janitor background task deletes them, after 60 days by default, a delay you configure. Transactions a user marked as favorite are kept. The default storage lives in memory and is lost at shutdown: point HARP at a database to keep history across restarts.

Finding a specific transaction

Recorded transactions are available in the dashboard, a single place to view and analyze the captured traffic. Search and filter let you pin down the one failing call, or surface a pattern that recurs across many.

Best-effort under load

Recording is best-effort. When the storage worker falls behind, it stops storing bodies first, then messages, then whole transactions, rather than slowing down live traffic. HARP recorded about 20 to 45 requests per second in full in one benchmark: PostgreSQL 16, with the proxy, the upstream, the load generator and the database on one shared 6 vCPU host, where the proxy's CPU was the limit. Treat the traffic history as an operational view of your traffic, not a complete account of it. It is not a compliance-grade audit trail: entries can be dropped under load, so do not rely on it as evidence.

Debugging and post-mortems

Access to the requests and responses lets developers reproduce and fix a problem instead of guessing at its cause. After an incident, the same record helps you trace the calls leading up to it and assess their impact.