Investigate user complaint

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:

Detail	Value
Service	`orders-api`
Customer ID	`cus_12345`
Approximate time	Today
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. Context is captured for every failed request, but only for a sample of successful requests (1% by default, set by ContextSamplingRate). If the customer’s request succeeded at the HTTP level, its context may not have been captured.

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. The timeline shows the inbound request, outbound HttpClient calls (as child executions), consumed MassTransit messages and BeginExecution scopes, plus the logs written during the execution. Look for:

request received
outbound calls to downstream services or providers, with their status and duration
logged exceptions
timeouts on outbound calls
final response

Database writes, cache operations and other work that Foveus does not instrument are not timeline steps. If your code logs them, they appear in the linked logs. The timeline helps you reconstruct the execution without jumping between logs and traces 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 (response bodies are off by default)
the request’s context was captured: successful requests are sampled at ContextSamplingRate
the key is not a redacted field such as email or phone; redacted values are stored as ***
telemetry was not delayed or lost: check for a “Telemetry incomplete” or “Telemetry delayed” banner in the dashboard

Recommended investigation flow

Use this flow when support reports a complaint:

Search by service.
Add known business context.
Add endpoint or method if known.
Open the matching execution.
Inspect response context and timeline.
Review linked logs.
Open the linked issue if there is one.
Record the root cause or next step.

What to do next

Learn about executions: Executions
Learn about context search: Execution Context Search
Debug an HTTP 500: Debug an HTTP 500
Review data safety: Data safety and retention

Start here

Get started

Core concepts

Guides

SDK

Security and data

API reference