Skip to main content
Use nested context search when the value you need is inside a structured response object. This is useful when your service or a third-party provider returns a business outcome in the response body. For example: 
{
  "orderStatus": {
    "value": 1,
    "label": "Confirmed"
  },
  "paymentStatus": {
    "value": 2,
    "label": "Pending"
  }
}
Foveus can index safe scalar fields from this response. Then you can search: 
service:orders-api context:orderStatus.value=1
or: 
service:orders-api context:paymentStatus.label="Pending"

​
When to use this

Use nested response context search when you know a value returned by your API or provider. Examples:
  • order status
  • payment status
  • provider response code
  • verification result
  • approval status
  • shipment status
  • risk decision
  • workflow result
This helps you find executions without manually searching logs.

​
Query format

Use context: with a dotted path. 
context:<object>.<field>=<value>
Example: 
context:orderStatus.value=1
When you know the service, include it: 
service:orders-api context:orderStatus.value=1
Adding service: keeps the search faster and more precise.

​
Strings need quotes

Use quotes for string values. 
service:orders-api context:orderStatus.label="Confirmed"
Numbers do not need quotes. 
service:orders-api context:orderStatus.value=1
Booleans do not need quotes. 
service:orders-api context:isApproved=true

​
Example: search by response status

Given this response: 
{
  "orderStatus": {
    "value": 2,
    "label": "Failed"
  }
}
Search by value: 
service:orders-api context:orderStatus.value=2
Search by label: 
service:orders-api context:orderStatus.label="Failed"

​
Example: search by provider response

Given this response: 
{
  "provider": {
    "name": "delivery-provider",
    "status": {
      "code": "PENDING_PICKUP",
      "message": "Package is waiting for pickup"
    }
  }
}
Search by provider status code: 
service:orders-api context:provider.status.code="PENDING_PICKUP"
Search by provider name: 
service:orders-api context:provider.name="delivery-provider"

​
Example: search by boolean result

Given this response: 
{
  "riskDecision": {
    "approved": false,
    "reason": "manual_review_required"
  }
}
Search for rejected decisions: 
service:orders-api context:riskDecision.approved=false
Search by reason: 
service:orders-api context:riskDecision.reason="manual_review_required"

​
Arrays of objects

If a response contains an array of objects, Foveus can index safe scalar child fields when array extraction is enabled. Given this response: 
{
  "statuses": [
    { "value": 1, "label": "Confirmed" },
    { "value": 2, "label": "Failed" }
  ]
}
Foveus can index: 
statuses.value = 1
statuses.label = Confirmed
statuses.value = 2
statuses.label = Failed
Then you can search: 
service:orders-api context:statuses.value=1
or: 
service:orders-api context:statuses.label="Failed"
For arrays, matching is existence-based. context:statuses.value=1 means at least one item in the array has value = 1.

​
Multiple nested fields

You can combine multiple context filters. 
service:orders-api context:orderStatus.value=2 context:paymentStatus.label="Pending"
Different context keys use AND. This means both indexed values must exist on the execution.

​
Search with status

Add status:failed when you only want failed executions. 
service:orders-api status:failed context:orderStatus.label="Failed"
This is useful when the same response value appears in both successful and failed flows.

​
Search with endpoint

Add endpoint: when you know the route. 
service:orders-api method:POST endpoint:/orders context:orderStatus.value=2
This is useful when the same response structure appears across multiple endpoints.

​
How Foveus indexes nested fields

Foveus indexes safe scalar fields from enabled context sources. For response context, nested objects become dotted paths. 
{
  "orderStatus": {
    "value": 1,
    "label": "Confirmed"
  }
}
becomes: 
orderStatus.value = 1
orderStatus.label = Confirmed
Foveus does not index every possible payload blindly. It applies safety controls before indexing.

​
Safety controls

Foveus applies controls such as:
  • redaction
  • sensitive-key denylist
  • scalar-only indexing
  • maximum value length
  • maximum traversal depth
  • maximum indexed properties per execution
  • allowed context sources
  • sampling and retention controls
Sensitive values should not be indexed.

​
If no result appears

Check:
  • the service name matches the execution service
  • the time range includes the execution
  • response body capture is enabled
  • the response value is scalar
  • the route was not excluded
  • the value was not redacted
  • the field was indexed after context indexing was enabled
  • the field is still within retention
  • the string value is quoted
For example: 
context:orderStatus.label="Confirmed"
not: 
context:orderStatus.label=Confirmed
  1. Start with the service.
  2. Add the nested response field.
  3. Add endpoint or method if known.
  4. Add status:failed if investigating failures.
  5. Open the matching execution.
  6. Inspect response context and timeline.
  7. Check linked logs or issues if available.

​
Useful examples

Find confirmed orders: 
service:orders-api context:orderStatus.label="Confirmed"
Find failed order responses: 
service:orders-api context:orderStatus.value=2
Find pending provider responses: 
service:orders-api context:provider.status.code="PENDING_PICKUP"
Find rejected risk decisions: 
service:orders-api context:riskDecision.approved=false
Find failed executions with a provider status: 
service:orders-api status:failed context:provider.status.code="TIMEOUT"

​
What to do next