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

# Debug http 500

Use Foveus to investigate HTTP 500 errors without starting from raw logs.

An HTTP 500 usually means the service failed while processing the request. Foveus helps you find the failed execution, inspect the timeline, review response context, and check whether the error belongs to a repeated issue pattern.

## Start with the service

Open **Executions**.

Search for failed executions in the affected service:

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

If you know the endpoint, add it:

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

Use the time range picker to include the period when the error happened.

## Open the failed execution

Open a matching execution.

Start with:

* endpoint
* method
* status
* duration
* outcome
* request context
* response context
* logs, if configured
* exception details, if available
* linked issue, if available

The goal is to understand what happened during this exact request.

## Check the execution timeline

Use the timeline to inspect the order of events.

Look for:

* request received
* validation step
* downstream call
* provider response
* database operation
* exception
* timeout
* final response

The timeline helps you see where the execution moved from normal behavior to failure.

## Inspect response context

If response context was captured, check what your service returned.

For example:

```json theme={null}
{
  "error": {
    "code": "ORDER_CREATE_FAILED",
    "message": "Unable to create order"
  }
}
```

You can search for similar executions by response fields:

```text theme={null}
service:orders-api context:error.code="ORDER_CREATE_FAILED"
```

This helps you find other executions with the same failure signal.

## Check provider or downstream responses

Some HTTP 500 errors are caused by downstream services or providers.

For example, your service may return HTTP 500 because a provider returned a failure response:

```json theme={null}
{
  "provider": {
    "name": "delivery-provider",
    "status": {
      "code": "TIMEOUT",
      "message": "Provider request timed out"
    }
  }
}
```

Search for matching provider responses:

```text theme={null}
service:orders-api context:provider.status.code="TIMEOUT"
```

Or narrow to failed executions:

```text theme={null}
service:orders-api status:failed context:provider.status.code="TIMEOUT"
```

## Check logs linked to the execution

If logs are configured, use linked logs to inspect log lines from the same execution.

Look for:

* exception messages
* stack traces
* failed provider calls
* timeout logs
* retry attempts
* validation failures
* database errors

Linked logs are useful because they are scoped to the execution. You do not need to search through unrelated log streams first.

## Check if Foveus created an issue

If the execution is linked to an issue, open the issue.

An issue can show:

* failure pattern
* common factors
* suggested diagnostic step
* representative execution
* linked executions
* recent activity
* lifecycle

Use the issue when the HTTP 500 is part of a repeated pattern.

For example:

```text theme={null}
HTTP 500 in orders-api
```

The issue can help you see whether this is a one-off failure or something recurring.

## Search for the same failure pattern

Use context, endpoint, and status filters to find related executions.

By endpoint:

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

By response error code:

```text theme={null}
service:orders-api context:error.code="ORDER_CREATE_FAILED"
```

By provider status:

```text theme={null}
service:orders-api context:provider.status.code="TIMEOUT"
```

By customer or business ID:

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

## Identify the failure boundary

When debugging HTTP 500 errors, try to identify where the failure happened.

| Evidence                        | Likely direction                                                |
| ------------------------------- | --------------------------------------------------------------- |
| Exception in your service       | Inspect application code and stack trace.                       |
| Provider failure response       | Inspect downstream/provider integration.                        |
| Timeout                         | Check provider latency, network, retries, or database timeouts. |
| Database error                  | Inspect query, migration, connection, or data constraint.       |
| Business response marked failed | Check outcome semantics and business rule handling.             |
| No useful context               | Check capture settings, redaction, sampling, and logs.          |

Foveus gives you evidence. You still decide the fix.

## Record the next step

After reviewing the execution, record the next step in the linked issue or your team workflow.

Good notes are specific:

```text theme={null}
Provider returned TIMEOUT for order creation. Next step: inspect retry behavior and provider latency for the affected time window.
```

Avoid vague notes:

```text theme={null}
Check logs.
```

## If no execution appears

Check:

* the service name matches the service shown in Foveus
* the dashboard is showing the correct mode
* the time range includes the error
* `status:failed` is not too restrictive
* the endpoint path matches the captured endpoint
* the route was not excluded by SDK configuration
* the SDK middleware is registered
* the execution is still within retention

## If response context is missing

Check:

* `CaptureResponseBodies` is enabled
* the route is not excluded
* the response body is within the capture size limit
* the response content type is supported
* redaction did not mask the value
* sampling did not skip the context snapshot

Example configuration:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "Mode": "live",
    "CaptureProfile": "Balanced",
    "CaptureResponseBodies": true,
    "ContextSamplingRate": 0.01,
    "ExcludedPathPrefixes": ["/health", "/metrics"]
  }
}
```

## Recommended workflow

1. Search failed executions by service.
2. Add endpoint or method if known.
3. Open a failed execution.
4. Inspect the timeline.
5. Review response context and provider evidence.
6. Check linked logs.
7. Open the linked issue if available.
8. Search for the same failure pattern.
9. Record the next diagnostic step.

## What to do next

* Learn about executions: [Executions](/concepts/executions)
* Learn about issues: [Issues](/concepts/issues)
* Search nested response context: [Search nested response context](/guides/search-nested-response-context)
* Review performance overhead: [Performance overhead](/sdk/performance-overhead)