title: “Executions” description: “Learn what an execution is and how Foveus uses executions to explain application behavior.”

Executions

An execution is one run of work in your application. For an API service, an execution is usually one HTTP request. For a worker, an execution may eventually represent one job, message, scheduled task, or background operation. Worker support is evolving, so HTTP request capture is currently the most complete execution boundary. 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 * outcome * logs * failure details * linked issue, if Foveus grouped it into one

Execution examples

An HTTP API request:

GET /orders/ord_12345

Each one can be represented as an execution model, but support varies by source.

HTTP execution capture is currently the most complete execution boundary. Worker services can send logs, exceptions, outbound HTTP telemetry, metrics, and trace context today, but full automatic per-job execution capture for arbitrary worker loops is still evolving.

What Foveus captures

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

Field	Description
`service`	The service that produced the execution.
`environment`	The deployment environment, such as `development`, `staging`, or `production`.
`mode`	The Foveus data mode: `test` or `live`.
`endpoint`	The HTTP path or operation name.
`method`	The HTTP method, such as `GET` or `POST`.
`duration`	How long the execution took.
`outcome`	Whether the execution succeeded, failed, or is unknown.
`context`	Safe request, response, query, or custom context fields.
`logs`	Logs correlated to the execution, if configured.
`issue`	The issue linked to the execution, if Foveus grouped it.

For worker services, Foveus can capture logs, logged exceptions, outbound HTTP telemetry, metrics, trace propagation, and supported messaging instrumentation hooks.

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:

builder.Services.AddFoveus(options =>
{
    options.ApiKey = builder.Configuration["Foveus:ApiKey"];
    options.ServiceName = "orders-api";
});

Use a service name your team recognizes.

orders-api
payments-api
identity-api
billing-worker

Foveus works with your existing service naming convention. If your organization uses environment-specific service names, you can keep using them.

Environment

Use Environment to describe where your service is running. Examples:

development
test
staging
production

This helps you separate the same service across deployments.

service:orders-api environment:production

Mode

Foveus has two modes:

Mode	Use for
`test`	Sandbox, development, QA, and onboarding
`live`	Production telemetry

Foveus defaults to test. Set Mode only when sending live telemetry.

{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "ServiceName": "orders-api",
    "Environment": "production",
    "Mode": "live"
  }
}

Outcomes

An execution can have an outcome such as:

Outcome	Meaning
`success`	The execution completed successfully.
`failed`	The execution failed or returned a failure response.
`unknown`	Foveus could not confidently classify the outcome.

Foveus can use HTTP status codes, response fields, exception data, and configured outcome semantics to determine the outcome.

Context

Execution context is structured data captured from the request, response, query string, or custom context. For example:

{
  "customerId": "cus_12345",
  "orderStatus": {
    "value": 1,
    "label": "Confirmed"
  }
}

You can search indexed context fields:

service:orders-api context:customerId="cus_12345"

Search nested fields with dotted paths:

service:orders-api context:orderStatus.value=1

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. For worker services, logs are currently one of the most useful telemetry sources.

Worker telemetry

Foveus can be used in .NET Worker Service and BackgroundService apps. Worker services use:

builder.Services.AddFoveus(builder.Configuration);

They do not use:

app.UseFoveus();

because workers do not have an ASP.NET HTTP middleware pipeline. Worker support currently includes: * ILogger logs * logged exceptions * outbound HTTP telemetry through IHttpClientFactory * trace and execution header propagation on outbound HTTP * SDK shutdown flushing * source classification as worker * supported MassTransit instrumentation hooks Full automatic per-job execution capture for arbitrary worker loops is not yet implemented. See Worker services.

Linked issues

Foveus can group failed executions into issues. An issue is a repeated or meaningful failure pattern. For example, several failed executions on the same endpoint may become one issue.

HTTP 500 in orders-api

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:

service:orders-api

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

service:orders-api status:failed

service:orders-api context:customerId="cus_12345"

service:orders-api context:orderStatus.value=1

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 * understand why a request failed * move from an issue to the exact failed execution * correlate logs with a unit of work For worker services, use Foveus today to inspect logs, exceptions, outbound HTTP activity, and supported messaging telemetry while full per-job execution capture evolves.

What to do next

* View your first execution: View your first execution * Search by context: Execution Context Search * Learn about issues: Issues * Set up worker services: Worker services * Investigate a user complaint: Investigate a user complaint

Start here

Get started

Core concepts

Guides

SDK

Security and data

API reference

Executions

title: “Executions” description: “Learn what an execution is and how Foveus uses executions to explain application behavior.”

Executions

Why executions matter

Execution examples

What Foveus captures

Service name

Environment

Mode

Outcomes

Context

Linked logs

Worker telemetry

Linked issues

Search executions

When to use executions

What to do next

​title: “Executions” description: “Learn what an execution is and how Foveus uses executions to explain application behavior.”

​Executions

​Why executions matter

​Execution examples

​What Foveus captures

​Service name

​Environment

​Mode

​Outcomes

​Context

​Linked logs

​Worker telemetry

​Linked issues

​Search executions

​When to use executions

​What to do next

title: “Executions” description: “Learn what an execution is and how Foveus uses executions to explain application behavior.”

Executions

Why executions matter

Execution examples

What Foveus captures

Service name

Environment

Mode

Outcomes

Context

Linked logs

Worker telemetry

Linked issues

Search executions

When to use executions

What to do next