Forensic analysis

When something goes wrong in a distributed system, an outage, a data discrepancy, or a security incident, you need to reconstruct what actually happened on the wire. HARP sits between your applications and the remote APIs they call, and its audit log records the transactions that pass through it. That record gives you the raw material for an investigation without instrumenting your application code.

Understanding the use case

Many tools tell you that a service was slow or returned an error. Fewer tell you exactly what was sent and what came back. Because HARP is a forward proxy on the path between your apps and their upstream APIs, it can capture each HTTP request and response, including headers and payloads. During an incident, that lets you look at the precise interactions involved rather than reasoning from logs and metrics alone.

What HARP records

The audit log stores the transactions passing through the proxy, both the request and the response, whether or not they were forwarded to a remote backend. It is enabled by default and needs no configuration to start collecting data. Records are kept for a configurable retention period, after which they are pruned automatically.

Two practical points matter for an investigation:

• Retention is finite. Investigate while the relevant transactions are still within the retention window, or set a longer retention period ahead of time.
• Capture can degrade under load. Under heavy load, HARP may skip storing some transactions to keep processing requests, so records from a traffic spike can be incomplete.

Investigating with the dashboard

The transactions you collect are available in the HARP dashboard, which is where most forensic work happens.

• Find the relevant transactions. Filter by endpoint, method, status, and more, and search to narrow a large volume of traffic down to the calls that matter.
• Inspect the content. Open a transaction to see its full request and response, so you can confirm exactly what data was exchanged and where a failure originated.
• Reconstruct the sequence. Work backward from the moment the incident surfaced, focusing on the providers and endpoints involved, to establish the order of events leading up to it.

What this gives you

• A concrete record. Instead of debating what each service sent, you can point to the stored request and response for a given transaction.
• Faster root-cause work. Filtering and content inspection let you move from a broad incident to the specific failing call without sifting through unrelated data.
• Shared context. Because everyone works from the same captured transactions, investigation and post-mortem discussion start from facts rather than reconstructions.

For more on how the underlying feature works, see the audit log feature.