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 is a free-text label that 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:

orders-api
payments-api
identity-service
billing-worker
notification-worker

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

builder.Services.AddFoveus("fov_test_...");

With this setup, Foveus automatically uses:

Option	Default
`ServiceName`	Project assembly name
`Environment`	`test` or `live`, taken from the API key

The fov_test_ key sends this telemetry to Test mode. You can override the service name when the default is not the name you want to see in Foveus.

{
  "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:

orders-api-dev
orders-api-staging
orders-api-prod

Other teams use the same logical service name across environments:

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:

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

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:

development
test
staging
production

If you do not set Environment, it is test or live, taken from the API key. It is not read from the ASP.NET Core environment (ASPNETCORE_ENVIRONMENT). Set it explicitly to name the deployment. You can override it:

{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "Environment": "staging"
  }
}

Service and environment examples

Local development

Minimal setup:

builder.Services.AddFoveus("fov_test_...");

Foveus uses your project assembly name as the service name, test as the environment, and Test mode (from the fov_test_ key). You can override values when needed:

{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "development"
  }
}

Staging

{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "staging"
  }
}

The fov_test_ key sends this telemetry to Test mode, even though the environment label is staging.

Production

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

The fov_live_ key sends this telemetry to Live mode. During private beta, live keys are issued by the Foveus team.

Mode is different from environment

Environment describes your deployment. The mode is the Foveus data boundary. The API key decides it; there is no mode setting.

Concept	Example	Meaning
Service	`orders-api`	The application, API, or worker producing telemetry
Environment	`production`	A label for where the service is running
Mode	`live`	The Foveus telemetry mode, decided by the API key prefix

These should not be treated as the same thing. For example, a staging deployment can send telemetry in Test mode:

{
  "Foveus": {
    "ApiKey": "fov_test_...",
    "ServiceName": "orders-api",
    "Environment": "staging"
  }
}

A production deployment should send telemetry in Live mode, using a live key:

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

Search by service

Use the service: filter on the Executions page.

service:orders-api

Combine it with other filters:

service:orders-api status:failed

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

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.

service:orders-api-prod

Search by environment

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

service:orders-api environment:production

Environment filtering may depend on your current Foveus version and dashboard support.

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:

orders-api
payments-api
billing-worker
notification-service

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

orders-api-dev
orders-api-staging
orders-api-prod

Avoid names that change on every deploy:

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 set Environment when:

you want to name the deployment, such as staging or production, instead of the default test or live
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
Learn about executions: Executions
Install the .NET SDK: Install the .NET SDK
Search by context: Execution Context Search

Start here

Get started

Core concepts

Guides

SDK

Security and data

API reference

Services and environments

Service name

Use your existing naming convention

When a stable service name helps

Environment

Service and environment examples

Local development

Staging

Production

Mode is different from environment

Search by service

Search by environment

Choosing names

When to override defaults

What to do next