What BitDive Captures in a Runtime Snapshot
A BitDive runtime snapshot is the recorded execution evidence behind one real request, message, or business flow.
It is the same runtime evidence that powers trace exploration in the dashboard, MCP analysis for AI agents, before and after trace comparison, and replay-based regression suites.
Think of it as an execution record, not a heap dump and not a packet sniffer.
At a Glance
| Layer | What BitDive Captures | Why It Matters |
|---|---|---|
| Entry point | endpoint, request method, headers, query params, request body, timestamps | reproduce the same scenario and understand what actually triggered the flow |
| Execution tree | service path, method call hierarchy, timing, ordering | see how the request really moved through the application |
| Method-level data | class name, method name, arguments, return values, exceptions | debug behavior at the code level instead of guessing from logs |
| SQL and database activity | SQL text, bind parameters, timings, query sequence | catch N+1 patterns, missing filters, slow queries, and unintended data access changes |
| HTTP and REST dependencies | URL, method, headers, request payload, response status, response payload | detect API drift and verify downstream compatibility |
| Kafka and messaging | topic, key, payload, processing flow | inspect what was published or consumed in one business scenario |
| Failures | exception class, message, stack trace, failing child call, error response | identify the real failure point and its surrounding context |
| Security layer | masked fields, filtered packages, selective capture rules | keep runtime evidence useful without exposing sensitive values |
What is available in a given snapshot depends on your configuration, instrumentation scope, and the technologies involved in that execution path.
What a Runtime Snapshot Usually Contains
1. Entry Point Context
BitDive records the real entry into the flow:
- incoming HTTP method and URL
- query parameters and headers
- request body
- timing information
- the service and endpoint that handled the request
This is what lets a developer or AI agent reason from the actual triggering input instead of an invented example.
2. Execution Tree and Method Flow
Inside that request, BitDive records the method-level execution tree:
- which methods ran
- in what order they ran
- how long each step took
- which child calls were triggered
- where the flow diverged or failed
This is the core of runtime context. It turns "the endpoint returned 500" into a concrete explanation of which method, query, or downstream dependency caused the problem.
3. Method Arguments, Return Values, and Exceptions
For instrumented methods, BitDive can capture:
- method arguments
- return values
- thrown exceptions
- stack traces and failure location
This is especially useful when a bug depends on one specific payload shape, one nullable field, or one edge-case object state that is hard to reconstruct from logs alone.
4. SQL and Database Behavior
When the flow touches a database, BitDive can show:
- SQL query text
- bind parameters
- database timings
- query sequence
This makes it possible to verify not only that a response was correct, but also that the internal data access behavior stayed correct after a change.
Typical use cases:
- finding N+1 queries
- spotting accidental extra queries after refactoring
- seeing why a filter or join changed the result
- comparing database behavior before and after a fix
5. Downstream HTTP and REST Calls
For outgoing API calls, BitDive records the actual runtime exchange:
- URL and HTTP method
- headers
- serialized request body
- response status
- response headers
- response body
This is why BitDive can detect runtime API regressions that schema-only checks often miss. If serialization changes, a header disappears, or an error contract drifts, the snapshot shows the real before and after difference.
6. Kafka and Messaging Interactions
For messaging flows, BitDive can capture:
- topic
- key
- payload
- the method path around publish or consume operations
This helps verify that a code change did not silently alter the messages your service emits or expects.
7. Failures, Timing, and Sequence
A runtime snapshot is not just about values. It also preserves behavior:
- which call failed first
- whether the call order changed
- whether a dependency call disappeared or was added
- how latency moved across the flow
That is why BitDive is useful for both correctness issues and performance regressions.
Where This Snapshot Shows Up
The same captured runtime evidence can be surfaced in multiple BitDive workflows:
- dashboard exploration: inspect traces, heatmaps, and service maps
- MCP for AI agents: give Cursor, Claude, or Windsurf direct runtime context
- before and after comparison: prove what changed after a code update
- replay-based regression suites: preserve intended behavior in CI and local development
One capture, multiple uses.
What BitDive Does Not Capture by Default
A runtime snapshot is broad, but it is not unrestricted.
BitDive does not act like:
- a source code export
- a full database dump
- a packet sniffer for traffic outside the instrumented application
- unrestricted shell or database access for AI agents
- a plaintext secret collector
For the deeper security model, see System Architecture and Secure Data Processing.
Masking and Data Privacy
BitDive is designed to keep runtime evidence useful without shipping raw secrets around.
By configuration, sensitive fields can be masked inside the Java agent before data leaves the JVM. Typical masked keywords include fields such as:
passwordtokensecretcookieauthorizationcredentialapiKey
You can also control:
- package filters
- method depth limits
- selective capture rules
- comparison and masking policies
See the Configuration Guide for operational settings and System Architecture for the security model.
Why This Matters
For developers, a runtime snapshot replaces guesswork with concrete evidence.
For AI agents, it provides the missing execution context needed to make a focused fix, compare before and after traces, and avoid broad speculative changes.
For QA and CI, it becomes the baseline material for replay-based verification.