You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: develop-docs/integrations/heroku.mdx
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,10 @@
1
1
---
2
2
title: Heroku Plugin
3
-
sidebar_title: Heroku
3
+
sidebar_title: Heroku (Legacy)
4
4
---
5
+
## Deprecation Warning
6
+
Heroku plugin is deprecated and will be removed on October 25, 2025. This plugin automatically tracked releases and deployments from your Heroku apps in Sentry, linking them to error tracking and performance monitoring.
7
+
You can still use Sentry with Heroku by setting up [Releases](https://docs.sentry.io/product/releases/). Releases let you track versions, commits, crash-free sessions, and more.
Copy file name to clipboardExpand all lines: develop-docs/integrations/slack/index.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@ After you update the `config.yml`, `sentry.conf.py`, or `devlocal.py` you need t
33
33
34
34
Now that you’ve created your app and updated your Sentry config, you can navigate to __Interactivity & Shortcuts__ under __Features__.
35
35
36
-
Toggle on __Interactivity__.
36
+
Toggle on __Interactivity & Shortcuts__.
37
37
38
38
Now you’ll be able to enter your **Request URL** (this is the location of your self-hosted Sentry) and **Options Load URL**:
39
39
@@ -119,7 +119,7 @@ Navigate to __Slash Commands__ under __Features__. Click __Create New Command__
119
119
120
120
121
121
<Alert title="Note">
122
-
When creating the slash command, don’t use `/sentry`. Do something like `/{your_name}-sentry`. If multiple apps are installed with the same slash command, the most recently installed one takes over.
122
+
If you're a Sentry employee, when creating the slash command avoid using `/sentry`, try something like `/{your_name}-sentry`. If multiple apps are installed with the same slash command, the most recently installed one takes over.
description: What to consider when preparing a new major.
4
+
sidebar_order: 50
5
+
---
6
+
7
+
Even if we decide to make a new major, it's important to prioritize user-friendliness, ease of migration, and backwards compatibility.
8
+
9
+
Upgrading requires effort. Every major increases the chances of folks staying on an older version forever.
10
+
11
+
Don't break existing APIs for a minor maintenance benefit on your end.
12
+
13
+
14
+
## Making Migrating Easier
15
+
16
+
Create a [migration guide](https://docs.sentry.io/platforms/python/migration/). Include easily understandable and copy-pastable examples wherever possible.
17
+
18
+
Many folks might try to upgrade using AI. Try it out yourself on an example project. Consider adding rules specifically for migrating.
19
+
20
+
21
+
## Dropping Version Support
22
+
23
+
When making a new major, consider whether we should drop support for an old Python version. There is data in Looker you can use to make an informed decision.
24
+
25
+
Investigate if we should drop support for old versions of frameworks and libraries. This is not feasible to do by hand as there's too many. For this purpose there is a small script in `scripts/update_integration_support.py` that automatically detects the effective lowest supported version based on our tests and package metadata. You can run the script after removing support for an old Python version, and it should automatically detect which minimum versions are no longer supported.
26
+
27
+
In order to fully specify the new minimum versions:
28
+
- Update `_MIN_VERSIONS` in `sentry_sdk/integrations/__init__.py`
29
+
- Update the lower bounds in `extras_require` in `setup.py`, if specified
30
+
- Update the documentation pages for the affected integrations (usually, the lowest supported version is mentioned at the bottom)
Copy file name to clipboardExpand all lines: develop-docs/sdk/telemetry/traces/index.mdx
+28Lines changed: 28 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,34 @@ Header Format:
128
128
129
129
The full spec is available in the [W3C Trace Context](https://www.w3.org/TR/trace-context/) specification.
130
130
131
+
### `traceIgnoreStatusCodes`
132
+
133
+
This SHOULD be a collection of integers, denoting HTTP status codes.
134
+
If suitable for the platform, the collection MAY also admit pairs of integers, denoting inclusive HTTP status code ranges.
135
+
136
+
The option applies exclusively to incoming requests, and therefore MUST only be implemented in server SDKs.
137
+
138
+
The SDK MUST honor this option by inspecting the [`http.response.status_code`](https://opentelemetry.io/docs/specs/semconv/registry/attributes/http/#:~:text=1437-,http.response.status_code,-int) attribute on each transaction/root span before it's finished.
139
+
If the value of this attribute matches one of the status codes in `traceIgnoreStatusCodes`, the SDK MUST set the transaction's [sampling decision](https://develop.sentry.dev/sdk/telemetry/traces/#sampling) to `not sampled`.
140
+
141
+
Note that a prerequisite to implement this option is that every HTTP server integration MUST record the [`http.response.status_code`](https://opentelemetry.io/docs/specs/semconv/registry/attributes/http/#:~:text=1437-,http.response.status_code,-int) attribute as defined in the OTEL spec.
142
+
143
+
The SDK MUST emit a debug log denoting why the transaction was dropped.
144
+
If the SDK implements client reports, it MUST record the dropped transaction with the `event_processor` discard reason.
145
+
146
+
This option MUST default to an empty collection if it's introduced in a release with a minor SemVer bump.
147
+
SDKs SHOULD set the default for this option to the following value (or equivalent if the implementation doesn't admit pairs of integers)
148
+
```
149
+
[[301, 303], [305, 399], [401, 404]]
150
+
```
151
+
at the earliest release with a major SemVer bump following its introduction.
152
+
153
+
The rationale for this option and default is to not consume a user's span quota to trace requests that are useless for debugging purposes (and can often be triggered by scanning bots).
154
+
155
+
Examples:
156
+
`[403, 404]`: don't sample transactions corresponding to requests with status code 403 or 404
157
+
`[[300, 399], [401, 404]]`: don't sample transactions corresponding to requests with status codes between 300 and 399 (inclusive) or between 401 and 404 (inclusive)
158
+
131
159
## `Event` Changes
132
160
133
161
As of writing, transactions are implemented as an extension of the `Event`
Copy file name to clipboardExpand all lines: docs/cli/releases.mdx
+5-12Lines changed: 5 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,24 +14,17 @@ Because releases work on projects you will need to specify the organization and
14
14
15
15
## Creating Releases
16
16
17
-
Releases are created with the `sentry-cli releases new` command. It takes at the very least a version identifier that uniquely identifies the releases. There are a few restrictions -- the release name cannot:
18
-
19
-
- contain newlines, tabulator characters, forward slashes(/), or back slashes(\\)
20
-
- be (in their entirety) period (.), double period (..), or space ( )
21
-
- exceed 200 characters
22
-
23
-
The value can be arbitrary, but for certain platforms, recommendations exist:
24
-
25
-
- for mobile devices use `package-name@version-number` or `package-name@version-number+build-number`. **Do not** use `VERSION_NUMBER (BUILD_NUMBER)` as the parenthesis are used for display purposes ([email protected]+2 becomes 1.0 (2)), so invoking them will cause an error.
26
-
- if you use a DVCS we recommend using the identifying hash (eg: the commit SHA, `da39a3ee5e6b4b0d3255bfef95601890afd80709`). You can let sentry-cli automatically determine this hash for supported version control systems with `sentry-cli releases propose-version`.
27
-
- if you tag releases we recommend using the release tag prefixed with a product or package name (for example, `[email protected]`).
17
+
Releases are created with the `sentry-cli releases new` command. It takes at the very least a version identifier that uniquely identifies the releases.
28
18
29
19
```bash
30
20
#!/bin/sh
31
21
sentry-cli releases new "$VERSION"
32
22
```
33
23
34
-
Releases can also be auto created by different systems. For instance upon uploading a source map a release is automatically created. Likewise releases are created by some clients when an event for a release comes in.
24
+
There are some release name restrictions and conventions to be aware of. [Learn more about naming releases](/product/releases/naming-releases/).
25
+
26
+
Releases can also be auto-created by different systems—for instance, upon uploading a source map, or by some clients when an event that is tagged with a release is ingested. Therefore, it's important to set the release name when building and deploying your application. Learn more in our [Releases](/platform-redirect/?next=/configuration/releases/) documentation.
Sentry can ingest [OpenTelemetry](https://opentelemetry.io) traces and logs directly via the [OpenTelemetry Protocol](https://opentelemetry.io/docs/specs/otel/protocol/). Sentry does not support ingesting OTLP metrics.
9
9
10
-
Sentry can ingest [OpenTelemetry](https://opentelemetry.io) traces directly via the [OpenTelemetry Protocol](https://opentelemetry.io/docs/specs/otel/protocol/). If you have an existing OpenTelemetry trace instrumentation, you can configure your OpenTelemetry exporter to send traces to Sentry directly. Sentry's OTLP ingestion endpoint is currently in development, and has a few known limitations:
If you have an existing OpenTelemetry trace instrumentation, you can configure your OpenTelemetry exporter to send traces to Sentry directly. Sentry's OTLP ingestion traces endpoint is currently in development, and has a few known limitations:
11
15
12
16
- Span events are not supported. All span events are dropped during ingestion.
13
-
- Span links are partially supported. We ingest and display span links, but they cannot be searched, filtered, or aggregated. Links are are shown in the [Trace View](/concepts/key-terms/tracing/trace-view/).
17
+
- Span links are partially supported. We ingest and display span links, but they cannot be searched, filtered, or aggregated. Links are shown in the [Trace View](/concepts/key-terms/tracing/trace-view/).
14
18
- Array attributes are partially supported. We ingest and display array attributes, but they cannot be searched, filtered, or aggregated. Array attributes are shown in the [Trace View](/concepts/key-terms/tracing/trace-view/).
15
-
- Sentry does not support ingesting OTLP metrics or OTLP logs.
16
19
17
20
The easiest way to configure an OpenTelemetry exporter is with environment variables. You'll need to configure the trace endpoint URL, as well as the authentication headers. Set these variables on the server where your application is running.
18
21
@@ -39,8 +42,215 @@ const sdk = new NodeSDK({
39
42
sdk.start();
40
43
```
41
44
42
-
You can find the values of Sentry's OTLP endpoint and public key in your Sentry project settings.
45
+
You can find the values of Sentry's OTLP traces endpoint and public key in your Sentry project settings.
46
+
47
+
1. Go to the [Settings > Projects](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/) page in Sentry.
48
+
2. Select a project from the list.
49
+
3. Go to the "Client Keys (DSN)" sub-page for this project under the "SDK Setup" heading.
50
+
51
+
## OpenTelemetry Logs
52
+
53
+
<Includename="feature-available-ea-logs.mdx" />
54
+
55
+
If you have an existing OpenTelemetry log instrumentation, you can configure your OpenTelemetry exporter to send logs to Sentry directly. Sentry's OTLP ingestion logs endpoint has the following known limitations:
56
+
57
+
- Array attributes are partially supported. We ingest and display array attributes, but they cannot be searched, filtered, or aggregated.
58
+
59
+
The easiest way to configure an OpenTelemetry exporter is with environment variables. You'll need to configure the trace endpoint URL, as well as the authentication headers. Set these variables on the server where your application is running.
You can find the values of Sentry's OTLP logs endpoint and public key in your Sentry project settings.
43
89
44
90
1. Go to the [Settings > Projects](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/) page in Sentry.
45
91
2. Select a project from the list.
46
92
3. Go to the "Client Keys (DSN)" sub-page for this project under the "SDK Setup" heading.
93
+
94
+
## Distributed Tracing between Sentry Instrumentation and OpenTelemetry Instrumentation
95
+
96
+
If you have a frontend or services instrumented with the Sentry SDK, and you are also instrumenting with OpenTelemetry, you can use the `propagateTraceparent` exposed in the Sentry SDK to propagate the W3C Trace Context `traceparent` header to the OpenTelemetry instrumentation. This will allow you to continue traces from Sentry instrumented services.
97
+
98
+
The following SDKs support the `propagateTraceparent` option:
Copy file name to clipboardExpand all lines: docs/organization/integrations/deployment/heroku/index.mdx
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,11 @@
1
1
---
2
-
title: Heroku
2
+
title: Heroku (Legacy)
3
3
sidebar_order: 1
4
4
description: "Learn more about Sentry's Heroku integration, which allows you to create releases in Sentry when your Heroku app is deployed."
5
5
---
6
-
7
-
This integration needs to be set up in each project for which you wish to use it. It is maintained and supported by the [Sentry community](https://open.sentry.io/).
6
+
## Deprecation Warning
7
+
Heroku integration on Sentry is deprecated and will be removed on October 28, 2025. This plugin automatically tracked releases and deployments from your Heroku apps in Sentry, linking them to error tracking and performance monitoring.
8
+
You can still install the Sentry Add-on on Heroku and use Sentry with Heroku by setting up [Releases](/product/releases/) yourself. Heroku integration on Sentry will no longer be available.
0 commit comments