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

# Services and environments

Foveus uses services and environments to organize telemetry from your applications.

A **service** is the application, API, worker, or background process that produced telemetry.

An **environment** describes where that service is running.

For example:

| Service      | Environment   |
| ------------ | ------------- |
| `orders-api` | `development` |
| `orders-api` | `staging`     |
| `orders-api` | `production`  |

This lets you search and compare telemetry across deployments.

## Service name

`ServiceName` identifies the service that produced the execution.

Examples:

```text theme={null}
orders-api
payments-api
identity-service
billing-worker
notification-worker
```

If you do not set `ServiceName`, Foveus uses your project assembly name.

```csharp theme={null}
builder.Services.AddFoveus("fov_test_...");
```

With this setup, Foveus automatically uses:

| Option        | Default                 |
| ------------- | ----------------------- |
| `ServiceName` | Project assembly name   |
| `Environment` | Current app environment |
| `Mode`        | `test`                  |

You can override the service name when the default is not the name you want to see in Foveus.

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api"
  }
}
```

## Use your existing naming convention

Foveus works with the service names your team already uses.

Some teams use environment-specific service names:

```text theme={null}
orders-api-dev
orders-api-staging
orders-api-prod
```

Other teams use the same logical service name across environments:

```text theme={null}
orders-api
```

Both approaches can work.

If your organization already uses environment-specific service names, you can keep using them. Foveus will capture and display the service name you send.

## When a stable service name helps

If you are setting up a new service or standardizing naming across a team, a stable logical service name plus an explicit environment can make analysis easier.

For example:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "ServiceName": "orders-api",
    "Environment": "production",
    "Mode": "live"
  }
}
```

This can help when you want to:

* compare the same service across environments
* avoid splitting one logical service into many service names
* search by one service name and filter by environment
* keep issue grouping and dashboards easier to scan

This is a recommendation, not a requirement.

## Environment

`Environment` describes where your service is running.

Examples:

```text theme={null}
development
test
staging
production
```

If you do not set `Environment`, Foveus uses your current app environment.

For ASP.NET Core services, this usually comes from the application environment, such as `Development`.

You can override it:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "Environment": "staging"
  }
}
```

## Service and environment examples

### Local development

Minimal setup:

```csharp theme={null}
builder.Services.AddFoveus("fov_test_...");
```

Foveus uses your project assembly name as the service name, your current app environment, and Test mode.

You can override values when needed:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "development"
  }
}
```

### Staging

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "staging"
  }
}
```

Foveus uses Test mode by default, so `Mode` is not required.

### Production

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "ServiceName": "orders-api",
    "Environment": "production",
    "Mode": "live"
  }
}
```

Set `Mode` to `live` only when sending production telemetry with a live key.

## Mode is different from environment

`Environment` describes your deployment.

`Mode` controls the Foveus data boundary.

| Concept     | Example      | Meaning                                             |
| ----------- | ------------ | --------------------------------------------------- |
| Service     | `orders-api` | The application, API, or worker producing telemetry |
| Environment | `production` | Where the service is running                        |
| Mode        | `live`       | The Foveus telemetry mode                           |

These should not be treated as the same thing.

For example, a staging deployment can send telemetry in Test mode:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "staging"
  }
}
```

A production deployment should send telemetry in Live mode:

```json theme={null}
{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "ServiceName": "orders-api",
    "Environment": "production",
    "Mode": "live"
  }
}
```

## Search by service

Use the `service:` filter on the Executions page.

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

Combine it with other filters:

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

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

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

For context search, adding a service filter keeps results faster and more precise.

If your organization uses environment-specific service names, search by the actual service name you send to Foveus.

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

## Search by environment

If environment filtering is available in your workspace, use it to narrow results by deployment.

```text theme={null}
service:orders-api environment:production
```

<Note>
  Environment filtering may depend on your current Foveus version and dashboard support.
</Note>

## Choosing names

Use names that your team recognizes.

If your team already has a naming convention, use it.

If you are choosing new names, prefer names that are:

* stable across deploys
* easy to recognize
* consistent across related services
* not tied to build numbers or temporary release names

Good examples:

```text theme={null}
orders-api
payments-api
billing-worker
notification-service
```

Environment-specific names can also work when they match how your team operates:

```text theme={null}
orders-api-dev
orders-api-staging
orders-api-prod
```

Avoid names that change on every deploy:

```text theme={null}
orders-api-v2026-06-01
orders-api-build-4892
```

## When to override defaults

You should override `ServiceName` when:

* your assembly name is not user-friendly
* multiple projects share a generic assembly name
* your team wants a different display name in Foveus
* you need consistent naming across deployments

You should override `Environment` when:

* your hosting environment name is not what you want to show in Foveus
* you want to normalize names such as `prod` to `production`
* you want consistent labels across teams

## What to do next

* Learn about Test and Live modes: [Test and Live modes](/concepts/test-and-live-modes)
* Learn about executions: [Executions](/concepts/executions)
* Install the .NET SDK: [Install the .NET SDK](/get-started/install-dotnet-sdk)
* Search by context: [Execution Context Search](/concepts/execution-context-search)