Reconstructing what happened on the wire last week

The incident was on Tuesday. It got escalated on Wednesday, and you were handed it on Thursday. This is how investigations actually arrive, and it is the case most observability tooling is worst at, because by Thursday the evidence has usually expired.

Why the data is usually gone

The eBPF tools that see traffic without instrumentation were mostly built to watch, not to remember. Pixie keeps roughly a day, in memory on each node, and says so plainly: it is a live debugger. Hubble keeps a ring buffer of recent flows unless you export them somewhere, with longer history sold separately. Kubeshark keeps whatever snapshot somebody thought to take while the problem was happening, which requires having been there. DeepFlow is the exception among them: it stores to ClickHouse and genuinely retains, though what it keeps is metrics and request logs rather than the requests themselves.

Metrics do survive, and they are the reason this feels solvable when it is not. A dashboard will confirm that error rates rose at 03:14 on Tuesday. It will not tell you which request failed, what was in it, or what came back, because an aggregate is precisely the thing that has discarded that.

What a retained record changes

Spider decodes each request and response as it is captured and indexes it into Elasticsearch in your own infrastructure, with the payloads and the packets that carried them. Retention is something you provision rather than something the product decides.

This is not a theoretical scale. At Flowbird, now Arrive, Spider captures and stores over a terabyte a day on a one-week rolling window, and the architecture is built to go further.

What you can then ask

Having the traffic is only half of it; the other half is finding the part that matters inside a week of it. Spider extracts configured fields from requests and responses as tags, so you can filter on a value your business actually recognises - an order reference, a site code, a customer identifier - rather than on infrastructure identity.

From a filtered set you get the sequence rather than a list: a waterfall across services with the timing of each hop, a sequence diagram of the exchange, and a map of what talked to what, across every decoded protocol at once. The question stops being "what did this service do" and becomes "what happened to this order", which is usually the question that was asked in the first place.

Security investigations

The same property matters after a security incident, where the decisive question is scope. Because the requests and responses are retained rather than summarised, you can establish what was actually reached and what was returned, and equally what was not touched. Being able to prove the negative is frequently the more valuable half.

The honest cost

Keeping traffic costs money, and Spider is billed on captured volume, so the cost is explicit rather than buried. That is the trade being made: retention is what makes a late investigation possible, and it is the part you are paying for. Capture is targeted, so pointing it at what you need to be able to answer about is how it stays proportionate. How volume pricing works →

Related

Competitor details checked on 9 August 2026 against vendor documentation.

Common questions

How long can Spider Analyzer keep captured traffic?
As long as you provision for. Traffic is indexed into Elasticsearch running in your own infrastructure, so retention is an operational decision rather than a product limit. At Flowbird, now Arrive, Spider captures and stores over a terabyte a day on a one-week rolling window, and the architecture is designed to scale beyond that.
Why can most eBPF tools not answer questions about last week?
Because they were built to watch rather than to remember. Pixie holds roughly a day in memory on each node. Hubble keeps a ring buffer of recent flows unless you export them. Kubeshark keeps the snapshots you took at the time. None of that is a flaw; it is a different purpose, and it means the data is gone by the time a slow investigation starts. DeepFlow is the exception and does retain, on ClickHouse, though it keeps metrics and request logs rather than the requests themselves.
Can I find every request that touched one order or one customer?
Yes, if the identifier appears in the traffic. Spider extracts configured fields from requests and responses as tags, so you can filter on a business value such as an order reference and see every communication carrying it, across all protocols at once, then draw the sequence as a waterfall.
Does keeping traffic cost more?
Yes, and Spider is billed on captured volume, so it is a direct cost rather than a hidden one. That is the honest trade: retention is what makes an investigation possible after the fact, and it is the part you are paying for. Targeting capture at what you actually need to see is how you keep it proportionate.
Can Spider Analyzer show what an attacker accessed?
Within the traffic it captured, yes, and that is the useful property: because the requests and responses themselves are retained, you can establish what was reached and, just as importantly, what was not. A metric can tell you that access increased. Only the record tells you what was returned.