Skip to main content
Use Foveus when a user reports a problem but does not have an execution ID, trace ID, or log reference. Start with what you know:
  • customer ID
  • user ID
  • request ID
  • order ID
  • transaction ID
  • endpoint
  • approximate time
  • service name
  • response value
  • error message
Then use Execution Context Search to find the execution.

​
Example complaint

A customer reports:
“My order was marked as failed, but I was charged.”
You know:
DetailValue
Serviceorders-api
Customer IDcus_12345
Approximate timeToday
Possible endpoint/orders

​
Step 1: Start with the service

Open Executions. Search by service: 
service:orders-api
Use the time range picker to include the period when the complaint happened.

​
Step 2: Search by business context

If the request or response contains a customer ID, search for it. 
service:orders-api context:customerId="cus_12345"
Foveus searches indexed execution context. It does not scan arbitrary raw request or response bodies.

​
Step 3: Narrow by endpoint

If you know the endpoint, add it to the query. 
service:orders-api endpoint:/orders context:customerId="cus_12345"
If you know the method, add that too. 
service:orders-api method:POST endpoint:/orders context:customerId="cus_12345"
Adding service and endpoint keeps the search faster and more precise.

​
Step 4: Open the execution

Open the matching execution. Inspect:
  • endpoint
  • method
  • status
  • duration
  • request context
  • response context
  • logs, if configured
  • outcome
  • failure evidence
  • linked issue, if available
The goal is to move from a vague complaint to a concrete execution.

​
Step 5: Check response context

If response context was captured, inspect what the service returned. For example: 
{
  "orderStatus": {
    "value": 2,
    "label": "Failed"
  },
  "paymentStatus": {
    "value": 1,
    "label": "Charged"
  }
}
You can search for nested response fields: 
service:orders-api context:orderStatus.label="Failed"
or: 
service:orders-api context:paymentStatus.label="Charged"
Strings should use quotes. Numbers and booleans do not need quotes. 
service:orders-api context:orderStatus.value=2

​
Step 6: Inspect the timeline

Use the execution timeline to understand what happened in order. Look for:
  • request received
  • validation result
  • downstream call
  • provider response
  • database write
  • exception
  • timeout
  • final response
The timeline helps you reconstruct the execution without jumping between logs, traces, and database queries first.

​
Step 7: Check linked logs

If logs are configured, review logs linked to the execution. Linked logs help you avoid searching through unrelated log streams. Look for:
  • provider request or response logs
  • validation failures
  • retry attempts
  • timeout messages
  • exception stack traces
  • business rule decisions

​
Step 8: Check linked issues

If Foveus grouped the execution into an issue, open the issue. The issue can show:
  • failure pattern
  • common factors
  • representative execution
  • linked executions
  • recent activity
  • comments
  • lifecycle
Use the issue when the complaint is part of a repeated failure pattern.

​
Step 9: Record the outcome

After investigation, record what happened. A useful note includes:
  • what failed
  • affected customer or operation
  • root cause, if known
  • next step
  • owner
  • expected resolution
Example: 
Customer order failed after payment provider returned a charged status but order finalization failed. Next step: inspect order finalization path and confirm whether reconciliation handled this case.

​
Useful queries

Find by customer: 
service:orders-api context:customerId="cus_12345"
Find by request ID: 
service:orders-api context:request_id="req_12345"
Find failed executions: 
service:orders-api status:failed
Find failed executions for a customer: 
service:orders-api status:failed context:customerId="cus_12345"
Find by endpoint: 
service:orders-api method:POST endpoint:/orders
Find by response status: 
service:orders-api context:orderStatus.label="Failed"
Find by nested numeric value: 
service:orders-api context:orderStatus.value=2

​
If no execution appears

Check:
  • the service name matches the execution service
  • the time range includes the complaint time
  • the context key was captured and indexed
  • the value is quoted if it is a string
  • the endpoint or method is not too restrictive
  • the route was not excluded by SDK configuration
  • request or response body capture was enabled if you are searching body fields
  • the execution is still within retention
Use this flow when support reports a complaint:
  1. Search by service.
  2. Add known business context.
  3. Add endpoint or method if known.
  4. Open the matching execution.
  5. Inspect response context and timeline.
  6. Review linked logs.
  7. Open the linked issue if there is one.
  8. Record the root cause or next step.

​
What to do next