# Error
LLMS index: [llms.txt](/llms.txt)
---
- [Error Attributes](#error-attributes)
- [Deprecated Error Attributes](#deprecated-error-attributes)
## Error Attributes
This document defines the shared attributes used to report an error.
**Attributes:**
| Key | Stability | Value Type | Description | Example Values |
| --- | --- | --- | --- | --- |
| `error.type` |  | string | Describes a class of error the operation ended with. [1] | `timeout`; `java.net.UnknownHostException`; `server_certificate_invalid`; `500` |
**[1] `error.type`:** The `error.type` SHOULD be predictable, and SHOULD have low cardinality.
When `error.type` is set to a type (e.g., an exception type), its
canonical class name identifying the type within the artifact SHOULD be used.
Instrumentations SHOULD document the list of errors they report.
The cardinality of `error.type` within one instrumentation library SHOULD be low.
Telemetry consumers that aggregate data from multiple instrumentation libraries and applications
should be prepared for `error.type` to have high cardinality at query time when no
additional filters are applied.
If the operation has completed successfully, instrumentations SHOULD NOT set `error.type`.
If a specific domain defines its own set of error identifiers (such as HTTP or RPC status codes),
it's RECOMMENDED to:
- Use a domain-specific attribute
- Set `error.type` to capture all errors, regardless of whether they are defined within the domain-specific set or not.
---
`error.type` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
| Value | Description | Stability |
| --- | --- | --- |
| `_OTHER` | A fallback error value to be used when the instrumentation doesn't define a custom value. |  |
## Deprecated Error Attributes
This document defines deprecated attributes used to report an error.
**Attributes:**
| Key | Stability | Value Type | Description | Example Values |
| --- | --- | --- | --- | --- |
| `error.message` | 
Use domain-specific error message attribute. For example, use `feature_flag.error.message` for feature flag errors. | string | A message providing more detail about an error in human-readable form. [2] | `Unexpected input type: string`; `The user has exceeded their storage quota` |
**[2] `error.message`:** `error.message` should provide additional context and detail about an error.
It is NOT RECOMMENDED to duplicate the value of `error.type` in `error.message`.
It is also NOT RECOMMENDED to duplicate the value of `exception.message` in `error.message`.
`error.message` is NOT RECOMMENDED for metrics or spans due to its unbounded cardinality and overlap with span status.