> ## Documentation Index
> Fetch the complete documentation index at: https://docs.foveus.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```text theme={null}
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.

```text theme={null}
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.

```text theme={null}
service:orders-api endpoint:/orders context:customerId="cus_12345"
```

If you know the method, add that too.

```text theme={null}
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:

```json theme={null}
{
  "orderStatus": {
    "value": 2,
    "label": "Failed"
  },
  "paymentStatus": {
    "value": 1,
    "label": "Charged"
  }
}
```

You can search for nested response fields:

```text theme={null}
service:orders-api context:orderStatus.label="Failed"
```

or:

```text theme={null}
service:orders-api context:paymentStatus.label="Charged"
```

Strings should use quotes.

Numbers and booleans do not need quotes.

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
service:orders-api context:customerId="cus_12345"
```

Find by request ID:

```text theme={null}
service:orders-api context:request_id="req_12345"
```

Find failed executions:

```text theme={null}
service:orders-api status:failed
```

Find failed executions for a customer:

```text theme={null}
service:orders-api status:failed context:customerId="cus_12345"
```

Find by endpoint:

```text theme={null}
service:orders-api method:POST endpoint:/orders
```

Find by response status:

```text theme={null}
service:orders-api context:orderStatus.label="Failed"
```

Find by nested numeric value:

```text theme={null}
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

## Recommended investigation flow

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

* Learn about executions: [Executions](/concepts/executions)
* Learn about context search: [Execution Context Search](/concepts/execution-context-search)
* Debug an HTTP 500: [Debug an HTTP 500](/guides/debug-http-500)
* Review data safety: [Data safety and retention](/security/data-safety-and-retention)