Skip to main content
An execution is one run of work in your application. For an API service, an execution is usually one HTTP request. For a worker job, it is one BeginExecution scope that you mark in code. For a MassTransit consumer, it is one consumed message, when Foveus instrumentation is configured. Foveus does not detect scheduler, cron or Hangfire jobs as executions. Foveus uses executions to show what happened, when it happened, how long it took, and what evidence was captured.

Why executions matter

Logs tell you what was written. Metrics tell you what changed. Traces show request flow. Executions show the actual unit of work you need to inspect. An execution can include:
  • service name
  • endpoint or operation
  • request context
  • response context
  • duration
  • status
  • logs
  • failure details
  • linked issue, if Foveus grouped it into one

Execution examples

An HTTP API request:
Outbound HttpClient calls, consumed MassTransit messages (when instrumented) and BeginExecution scopes are also recorded as executions. See Executions.

What Foveus captures

The exact data depends on your SDK configuration and service type. A typical HTTP execution can include:

Service name

Foveus uses the service name to group executions by logical service. If you do not set ServiceName, Foveus uses your project assembly name. You can override it in configuration:
Use a stable logical service name.
Avoid putting the environment inside the service name.
Instead, keep the service name stable and use Environment.

Environment

Use Environment as a free-text label for where the service is running. When you do not set it, it is test or live, taken from the API key. It is not the ASP.NET Core environment. Examples:
This helps you separate the same service across deployments.

Mode

Foveus has two modes: The API key decides the mode. There is no separate mode setting. A live key sends to Live mode:

Status

An execution has one of these statuses:

Context

Execution context is structured data captured from the request, response, query string, or custom context. By default, context is captured for every failed request and for 1% of successful requests (ContextSamplingRate is 0.01). Response bodies are not captured unless you enable CaptureResponseBodies. A successful request whose context was not sampled cannot be found by context search. For example:
You can search indexed context fields:
Search nested fields with dotted paths:
Strings should use quotes. Numbers and booleans do not need quotes.
Execution Context Search uses indexed execution context. It does not scan arbitrary raw request bodies.

Linked logs

If logging is configured, Foveus can show logs related to an execution. This helps you inspect the log lines that occurred during the same unit of work instead of searching through unrelated log streams.

Linked issues

Foveus can group failed executions into issues. An issue is an observed recurring failure pattern, grouped by failure signature. It describes what was observed; it is not a confirmed root cause. For example, several failed executions on the same endpoint may become one issue.
Open the issue to see:
  • failure pattern
  • representative execution
  • linked executions
  • recent activity
  • lifecycle
  • comments and activity history

Search executions

The Executions page is query-first because execution data can be high-volume. Common searches:
For best performance and precision, start with a service filter when searching by context.

When to use executions

Use executions when you need to:
  • investigate a support complaint
  • find a request by customer ID or request ID
  • inspect request and response context
  • inspect the evidence for a failed request
  • move from an issue to the exact failed execution
  • correlate logs with a unit of work

What to do next