Last updated: May 7, 2026
Other Platform Resources
This page documents how Dash0 identifies and names resources for Heroku, Vercel, CI/CD systems, browser applications, and service-based equality.
This page covers platforms and fallback mechanisms not covered by the major cloud providers. For Kubernetes, AWS, and GCP, see their respective platform pages.
Heroku
Heroku resources are identified by combining application and dyno identifiers.
Equality Rules
For Heroku applications:
- By App and Dyno:
heroku.app.id+service.instance.id(each dyno within an app is a distinct resource)
Naming Rules
| Condition | Name |
|---|---|
heroku.app.id set | <heroku.app.id>:<service.instance.id> or <heroku.app.id> |
Typing Rules
| Condition | Type | UI Label |
|---|---|---|
heroku.app.id set | heroku.dyno | Heroku Dyno |
Vercel
Vercel resources are identified by deployment and project identifiers, with a service-based fallback.
Equality Rules
For Vercel deployments:
- By Deployment and Project:
vercel.deployment_id(orvercel.deploymentIdorvercel.sha) +vercel.project_id(orvercel.projectId) - Fallback (no project ID):
vercel.deployment_id(orvercel.deploymentIdorvercel.sha) + service triplet (service.namespace+service.name+service.instance.id)
The deployment identifier is required for matching but excluded from the resource hash, allowing different deployments of the same project to be tracked separately.
Naming Rules
| Condition | Name |
|---|---|
vercel.project_name set | <vercel.project_name> |
Typing Rules
| Condition | Type | UI Label |
|---|---|---|
| Vercel deployment identifier + project identifier set | vercel.project | Vercel Project |
Browser and Mobile Applications
Browser and mobile applications are identified using service triplets, with each unique configuration treated as a distinct resource.
Browser and mobile application detection happens FIRST, before any other platform rules are evaluated. This ensures that client-side telemetry is always classified correctly regardless of other attributes present.
Equality Rules
For web applications, Real User Monitoring, and native mobile apps:
- Browser Applications: When
telemetry.sdk.language == "webjs"orprocess.runtime.name == "browser", resources are identified by the service triplet - Native Mobile Apps: When
telemetry.sdk.language == "swift"ordevice_namecontains "iphone" (case-insensitive), resources are identified by the service triplet - JavaScript with Native Context: When
native.os.nameis set, resources are identified by the service triplet
Each unique combination of browser or device attributes creates a distinct resource to prevent incorrect merging of sessions with different configurations (user agents, screen sizes, device models, etc.)
Naming Rules
For browser and mobile applications, the name is constructed from available service attributes:
| Condition | Name |
|---|---|
service.namespace, service.name, and service.instance.id set | <service.namespace>:<service.name>:<service.instance.id> |
service.namespace and service.name set | <service.namespace>:<service.name> |
service.name and service.instance.id set | <service.name>:<service.instance.id> |
service.name only | <service.name> |
Typing Rules
| Condition | Type | UI Label |
|---|---|---|
| Any browser or mobile application detected | browser | Website |
All client-side applications (web browsers, mobile apps, and native applications) receive the same resource type browser in the current implementation. This includes Swift SDK instrumentation, iOS devices, and JavaScript applications with native contexts.
Each unique combination of browser/device attributes (user agent, screen size, device model, OS version, etc.) creates a distinct resource. This prevents incorrect merging of telemetry from different configurations, ensuring accurate Real User Monitoring metrics across diverse client environments.
Workflows and Pipelines
CI/CD pipeline resources are identified by pipeline execution identifiers.
Equality Rules
For CI/CD systems like Digibee Pipelines:
- By Realm and Pipeline:
realm+pipelineName(orpipelineKey)
Naming Rules
| Condition | Name |
|---|---|
realm and pipelineName (or pipelineKey) set | <realm>: <pipelineName> |
Typing Rules
| Condition | Type | UI Label |
|---|---|---|
| Pipeline attributes present | workflow | Workflow |
Cloud Account Resources
When cloud provider and account information is present but no service-specific attributes are available, resources can fall back to cloud account-level identification.
Equality Rules
For cloud account-level resources:
- By Cloud Account:
cloud.account.id+cloud.provider+cloud.platform
This rule identifies resources at the cloud account level when more specific resource identifiers are not available.
Typing Rules
| Condition | Type | UI Label |
|---|---|---|
cloud.account.id + cloud.provider set | cloud.account | Cloud Account |
This fallback ensures that telemetry with cloud provider information but no service-specific identifiers still gets correlated by cloud account. This is useful for account-level metrics and events.
Service Triplet
Service-based equality provides a fallback mechanism when no platform-specific attributes are available.
Equality Rules
As a fallback, resources can be identified by the service triplet (see service semantic conventions):
- By Service Identity:
service.namespace+service.name+service.instance.id
To use service-based resource equality, set these environment variables:
12OTEL_SERVICE_NAME=my-serviceOTEL_RESOURCE_ATTRIBUTES="service.instance.id=instance-123"
Service equality has the lowest priority to avoid overriding more specific technology-based equalities.
Naming Rules
When none of the technology-specific rules match, Dash0 falls back to service-based naming:
| Condition | Name |
|---|---|
service.namespace, service.name, and service.instance.id set | <service.namespace>:<service.name>:<service.instance.id> |
service.namespace and service.name set | <service.namespace>:<service.name> |
service.name and service.instance.id set | <service.name>:<service.instance.id> |
service.name only | <service.name> |
With OpenTelemetry moving toward SDK-set service.instance.id attributes, service-based naming is intentionally low priority. Use the technology-specific rules or dash0.resource.name for more meaningful names.
Typing Rules
No specific type is assigned for service-based resources. To assign a custom type, explicitly set dash0.resource.type in your OpenTelemetry SDK configuration.
Further Reading
For more information on resource equality rules and configurations, explore the following resources.
Related Topics in This Section
- About Resources: Overview of resources in Dash0
- Explore Resources: Get started exploring resources in Dash0
- Why Resource Equality?: Practical examples of resource fragmentation scenarios
Dash0 Guides & Knowledge
- What are OpenTelemetry Resources?: Deep dive into how resources describe which system is generating telemetry data
- Service Attributes Best Practices: Learn what resource attributes are and how they can be categorized
- Kubernetes Attributes Best Practices: Best practices for Kubernetes resource attributes
OpenTelemetry Resources
- Service Semantic Conventions: Service name, namespace, and instance ID
- FaaS Semantic Conventions: Serverless function attributes
- CI/CD Semantic Conventions: Pipeline and run attributes
- OpenTelemetry SDKs: Language-specific SDK documentation