Skip to main content
A request’s status and duration describe its completion and elapsed time. Understanding the operation also requires its call path and the data passed between functions. Vexlo changes the unit of instrumentation from a message to a function. A log statement defines which values to emit. An instrumented function contributes its arguments, return value, errors and call relationships to each recorded execution automatically. You select the function once, rather than adding a separate field or message for each value. The execution graph is the resulting data model: calls and captured values form one record that you can query after the operation has finished.

​
The same result, two ways of reading it

Consider a checkout that should apply a loyalty discount before tax. This recording comes from a revision with a pricing defect. The checkout completes, reserves inventory and authorizes payment, but returns a total of 3564 cents instead of 3208. The application logs:
The message gives the order identifier, acceptance result and total. It does not contain the customer’s membership field, the discount function’s arguments or the discount it returned. Searching this message cannot supply those omitted values after the request has finished. The execution graph records the path through pricing as well as validation, inventory and payment. Reading discount_for, a successful call inside price_order, gives:
The customer was a loyalty member and the subtotal was 3300 cents, but the discount function returned zero. That localizes the incorrect calculation before inspecting payment or changing retry behavior. The complete investigation follows the recording to the source mismatch, a regression test and a new recording after the correction. An existing log or span that already includes the relevant inputs and calculated discount can answer this question too. The distinction is the instrumentation decision. With Vexlo, recording the pricing functions preserves their arguments and results without adding a separate field or message for every intermediate value that could later matter.

​
Calls and data are one record

More messages alone do not define the execution graph. The recording associates each call with its recorded parent, values and attempts. Two invocations of the same function can be separate calls, while a declared retry can retain failed and successful attempts of one call. This structure lets a reader move from a result to the calls that produced it. It also gives an agent a concrete object to query: find the operation, read its graph, then request data from selected calls. The agent does not need to infer those recorded parent relationships from independent message timestamps. Across executions, function metadata exposes observed callers, callees and retained examples. That makes the same recording useful for understanding code, preparing changes and deriving test inputs, as well as diagnosing unexpected behavior.

​
The instrumentation boundary still matters

Vexlo is selective. A function must be instrumented to appear, and a branch must execute to be observed. Captured values are representations subject to data controls and bounds. Observed relationships establish use in the recorded executions, not all possible callers. Use Capture controls to decide which data can be recorded.

​
Run independently or alongside existing tools

Vexlo can run alongside existing logs and distributed tracing, or independently when recorded execution is the evidence you need. It does not require another telemetry backend. If both systems record the same request identifier, use it to find the corresponding Vexlo recording. Vexlo’s scope is recorded execution for developers and agents. A general metrics, dashboard and alerting platform is outside its scope. Quickstart records a first execution; The execution graph explains the model in detail.