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: This lets you search and compare telemetry across deployments.

​
Service name

ServiceName identifies the service that produced the execution. Examples:
If you do not set ServiceName, Foveus uses your project assembly name.
With this setup, Foveus automatically uses: You can override the service name when the default is not the name you want to see in Foveus.

​
Use your existing naming convention

Foveus works with the service names your team already uses. Some teams use environment-specific service names:
Other teams use the same logical service name across environments:
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:
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:
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:

​
Service and environment examples

​
Local development

Minimal setup:
Foveus uses your project assembly name as the service name, your current app environment, and Test mode. You can override values when needed:

​
Staging

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

​
Production

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. These should not be treated as the same thing. For example, a staging deployment can send telemetry in Test mode:
A production deployment should send telemetry in Live mode:

​
Search by service

Use the service: filter on the Executions page.
Combine it with other filters:
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.

​
Search by environment

If environment filtering is available in your workspace, use it to narrow results by deployment.
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:
Environment-specific names can also work when they match how your team operates:
Avoid names that change on every deploy:

​
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