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:

service:orders-api status:failed

If you know the endpoint, add it:

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:

{
  "error": {
    "code": "ORDER_CREATE_FAILED",
    "message": "Unable to create order"
  }
}

You can search for similar executions by response fields:

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:

{
  "provider": {
    "name": "delivery-provider",
    "status": {
      "code": "TIMEOUT",
      "message": "Provider request timed out"
    }
  }
}

Search for matching provider responses:

service:orders-api context:provider.status.code="TIMEOUT"

Or narrow to failed executions:

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:

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:

service:orders-api status:failed method:POST endpoint:/orders

By response error code:

service:orders-api context:error.code="ORDER_CREATE_FAILED"

By provider status:

service:orders-api context:provider.status.code="TIMEOUT"

By customer or business ID:

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:

Provider returned TIMEOUT for order creation. Next step: inspect retry behavior and provider latency for the affected time window.

Avoid vague notes:

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:

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

Recommended workflow

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

What to do next

Learn about executions: Executions
Learn about issues: Issues
Search nested response context: Search nested response context
Review performance overhead: Performance overhead

​Start with the service

​Open the failed execution

​Check the execution timeline

​Inspect response context

​Check provider or downstream responses

​Check logs linked to the execution

​Check if Foveus created an issue

​Search for the same failure pattern

​Identify the failure boundary

​Record the next step

​If no execution appears

​If response context is missing

​Recommended workflow

​What to do next