Skip to main content
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:
ServiceEnvironment
orders-apidevelopment
orders-apistaging
orders-apiproduction
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:
OptionDefault
ServiceNameProject assembly name
EnvironmentCurrent app environment
Modetest
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",
    "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: 
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: 
{
  "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, your current app environment, and Test mode. 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"
  }
}
Foveus uses Test mode by default, so Mode is not required.

​
Production

{
  "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.
ConceptExampleMeaning
Serviceorders-apiThe application, API, or worker producing telemetry
EnvironmentproductionWhere the service is running
ModeliveThe Foveus telemetry mode
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: 
{
  "Foveus": {
    "ApiKey": "fov_live_...",
    "ServiceName": "orders-api",
    "Environment": "production",
    "Mode": "live"
  }
}

​
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 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