# AppSignal changelog ## Resize the trace timeline and open traces from browser errors 2026-10-26 · App · [www.appsignal.com/changelog/app/2026-10-26-distributed-tracing-preview](https://www.appsignal.com/changelog/app/2026-10-26-distributed-tracing-preview) Our service map no longer sits behind a feature flag, so every account can open it. It shows the services a traced request reached, and how long each call between them took. The trace timeline, browser errors, and links to expired traces got updates too. **The trace timeline overlay** gives the span column a resize grip. Drag it wider to read a long span name, or scroll the column sideways. The column no longer cuts span names off at a fixed width. The overlay now works on every screen width: on a phone, it drops its side and bottom spacing, so the timeline uses the whole screen. ![The trace timeline overlay on a phone, filling the screen, with span names shown in full next to their durations.](/assets/changelog/2026-10/distributed-tracing-preview-trace-timeline-phone.png "The trace timeline overlay uses the whole screen on a phone.") We had already announced how you can [follow a failed browser request into your back end](https://www.appsignal.com/changelog/app/2026-10-13-browser-distributed-tracing). Now, **Browser errors** also show their trace and related log lines in the side panel. Any network breadcrumb can also open its trace with **Open trace**. ![The Breadcrumbs list for a browser error, with the Open trace tooltip shown on the button next to a network request to /api/boom/.](/assets/changelog/2026-10/distributed-tracing-preview-network-breadcrumb-trace.png "Open trace on a network breadcrumb opens the trace for that request.") **A link to an expired trace** no longer dead-ends. AppSignal opens the latest trace for that incident and explains why you are looking at a different one. Read the [distributed tracing docs](https://docs.appsignal.com/distributed-tracing) to set it up. Tell us what you think in our [Discord channel](https://discord.gg/EjF6ykYx63). --- ## Link GitHub issues to incidents 2026-10-26 · App · [www.appsignal.com/changelog/app/2026-10-26-github-issue-linking](https://www.appsignal.com/changelog/app/2026-10-26-github-issue-linking) An incident can now link to more than one GitHub issue or pull request. Mention one in a note on the incident, with its URL or the `owner/repo#123` shorthand, and AppSignal links it. The logbook records **Linked #123 on GitHub**. The **Actions** panel shows a **View #123 in GitHub** button for each linked issue. Hover over it to see when AppSignal linked the issue. **Send to GitHub** keeps creating new issues as before. ![An incident summary with a note containing a GitHub issue URL, the Linked #6 on GitHub logbook entry, and the View #6 in GitHub action](/assets/changelog/2026-10/github-linked-issue.png) Read the [GitHub integration docs](https://docs.appsignal.com/application/integrations/github/create-github-issue#link-an-existing-issue-or-pull-request) to learn more. This feature is part of [AppSignal Labs](https://docs.appsignal.com/labs). --- ## Reject certs from compromised eMudhra intermediates 2026-10-23 · Wrap · 0.3.4 · Security · [www.appsignal.com/changelog/wrap/2026-10-23-09-29-wrap-0.3.4](https://www.appsignal.com/changelog/wrap/2026-10-23-09-29-wrap-0.3.4) ## Security - Reject certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), in addition to no longer trusting the root certificates they chain to. View the [Wrap v0.3.4 changelog](https://github.com/appsignal/appsignal-wrap/blob/main/CHANGELOG.md#034) for more information. --- ## Reject certs from compromised eMudhra intermediates 2026-10-23 · Kubernetes · 1.2.5 · Security · [www.appsignal.com/changelog/kubernetes/2026-10-23-09-31-kubernetes-1.2.5](https://www.appsignal.com/changelog/kubernetes/2026-10-23-09-31-kubernetes-1.2.5) ## Security - Reject certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), in addition to no longer trusting the root certificates they chain to. View the [Kubernetes v1.2.5 changelog](https://github.com/appsignal/appsignal-kubernetes/blob/main/CHANGELOG.md#125) for more information. --- ## Reject certs from compromised eMudhra intermediates 2026-10-23 · Collector · 0.11.11 · Security · [www.appsignal.com/changelog/collector/2026-10-23-09-35-collector-0.11.11](https://www.appsignal.com/changelog/collector/2026-10-23-09-35-collector-0.11.11) ## Security - Reject certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), in addition to no longer trusting the root certificates they chain to. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Remove eMudhra roots from fallback certificates 2026-10-23 · Ruby · 5.0.7 · Security · [www.appsignal.com/changelog/ruby/2026-10-23-09-56-ruby-5.0.7](https://www.appsignal.com/changelog/ruby/2026-10-23-09-56-ruby-5.0.7) ## Security - Bump the bundled certificates that the agent uses when it can't open the configured CA file. They no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which [compromised eMudhra intermediate certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) chain to. View the [Ruby gem v5.0.7 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#507) for more information. --- ## Remove eMudhra roots from fallback certificates 2026-10-23 · Ruby · 4.10.6 · Security · [www.appsignal.com/changelog/ruby/2026-10-23-09-57-ruby-4.10.6](https://www.appsignal.com/changelog/ruby/2026-10-23-09-57-ruby-4.10.6) ## Added - Automatically detect the application's revision from the `HEROKU_BUILD_COMMIT` environment variable, which is set by Heroku at build time [when the `runtime-dyno-build-metadata` Heroku Labs feature](https://devcenter.heroku.com/articles/dyno-metadata) is enabled. ## Security - Bump the bundled certificates that the agent uses when it can't open the configured CA file. They no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which [compromised eMudhra intermediate certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) chain to. View the [Ruby gem v4.10.6 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4106) for more information. --- ## Remove eMudhra roots from fallback certificates 2026-10-23 · Elixir · 2.18.4 · Security · [www.appsignal.com/changelog/elixir/2026-10-23-10-03-elixir-2.18.4](https://www.appsignal.com/changelog/elixir/2026-10-23-10-03-elixir-2.18.4) ## Security - Bump the bundled certificates that the agent uses when it can't open the configured CA file. They no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which [compromised eMudhra intermediate certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) chain to. View the [Elixir package v2.18.4 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2184) for more information. --- ## Remove eMudhra roots from fallback certificates 2026-10-23 · Python · 1.9.4 · Security · [www.appsignal.com/changelog/python/2026-10-23-10-11-python-1.9.4](https://www.appsignal.com/changelog/python/2026-10-23-10-11-python-1.9.4) ## Security - Bump the bundled certificates that the agent uses when it can't open the configured CA file. They no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which [compromised eMudhra intermediate certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) chain to. View the [Python package v1.9.4 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#194) for more information. --- ## Remove eMudhra roots from fallback certificates 2026-10-23 · Node.js · 3.9.4 · Security · [www.appsignal.com/changelog/nodejs/2026-10-23-10-12-node.js-3.9.4](https://www.appsignal.com/changelog/nodejs/2026-10-23-10-12-node.js-3.9.4) ## Security - Bump the bundled certificates that the agent uses when it can't open the configured CA file. They no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which [compromised eMudhra intermediate certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) chain to. View the [Node.js package v3.9.4 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#394) for more information. --- ## Set an Apdex target from the Discover page 2026-10-23 · App · [www.appsignal.com/changelog/app/2026-10-23-apdex-target-discover-page](https://www.appsignal.com/changelog/app/2026-10-23-apdex-target-discover-page) The **Discover AppSignal** page has a new side quest: **Set an Apdex target**. [Apdex](https://www.appsignal.com/changelog/app/2026-09-16-apdex) turns your response times into one score between 0 and 1, which shows how satisfied your users are with your app's performance. The side quest helps you set the response times AppSignal scores your requests against, so your score reflects what fast means for your app. ![The Set an Apdex target side quest on the Discover AppSignal page](/assets/changelog/2026-10/discover-apdex-target-side-quest.png) Apdex is part of [AppSignal Labs](https://docs.appsignal.com/labs). Read the [Apdex documentation](https://docs.appsignal.com/metrics/apdex) to learn how AppSignal scores your requests. Tell us what you think in our [Discord channel](https://discord.gg/EjF6ykYx63). --- ## Ask your agent to count your logs 2026-10-23 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-23-mcp-count-log-lines](https://www.appsignal.com/changelog/tools/2026-10-23-mcp-count-log-lines) Your agent can now count your logs through the AppSignal MCP. AppSignal does the counting, so your agent gets the answer without reading every log line. Try asking: - "Which request paths logged the most errors in the last hour?" - "How many 500 responses did each host log today?" - "Count this morning's checkout logs by severity." Your agent can break counts down by any field in your logs, and add up or average numeric fields, such as a duration. If you ask the same question every day, ask your agent to turn it into a log line action, so you can chart it or set an alert on it. New to the AppSignal MCP? The [setup guide](https://docs.appsignal.com/mcp/setup) shows you how to connect your agent. Tell us what you think in our [MCP Discord channel](https://discord.gg/fT2cbMuQSJ). --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Elixir · 2.18.3 · Security · [www.appsignal.com/changelog/elixir/2026-10-22-07-47-elixir-2.18.3](https://www.appsignal.com/changelog/elixir/2026-10-22-07-47-elixir-2.18.3) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. View the [Elixir package v2.18.3 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2183) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Ruby · 5.0.6 · Security · [www.appsignal.com/changelog/ruby/2026-10-22-07-48-ruby-5.0.6](https://www.appsignal.com/changelog/ruby/2026-10-22-07-48-ruby-5.0.6) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. ## Changed - Update appsignal dependency to 5.0.6. View the [Ruby gem v5.0.6 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#506) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Python · 1.9.3 · Security · [www.appsignal.com/changelog/python/2026-10-22-07-50-python-1.9.3](https://www.appsignal.com/changelog/python/2026-10-22-07-50-python-1.9.3) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. View the [Python package v1.9.3 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#193) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Ruby · 4.10.5 · Security · [www.appsignal.com/changelog/ruby/2026-10-22-08-02-ruby-4.10.5](https://www.appsignal.com/changelog/ruby/2026-10-22-08-02-ruby-4.10.5) ## Fixed - Fix issues in the extension that lead to gaps in data reporting. - Improve handling of the extension internal queue when full. ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. View the [Ruby gem v4.10.5 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4105) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Collector · 0.11.10 · Security · [www.appsignal.com/changelog/collector/2026-10-22-08-07-collector-0.11.10](https://www.appsignal.com/changelog/collector/2026-10-22-08-07-collector-0.11.10) ## Fixed - Group performance metrics for the same action better together. ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which those intermediates chain to. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Tools (API, MCP, CLI) · 2.2.2 · Security · [www.appsignal.com/changelog/tools/2026-10-22-08-18-cli-2.2.2](https://www.appsignal.com/changelog/tools/2026-10-22-08-18-cli-2.2.2) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. View the [CLI v2.2.2 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#222) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Kubernetes · 1.2.4 · Security · [www.appsignal.com/changelog/kubernetes/2026-10-22-18-51-kubernetes-1.2.4](https://www.appsignal.com/changelog/kubernetes/2026-10-22-18-51-kubernetes-1.2.4) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which those intermediates chain to. View the [Kubernetes v1.2.4 changelog](https://github.com/appsignal/appsignal-kubernetes/blob/main/CHANGELOG.md#124) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Node.js · 3.9.3 · Security · [www.appsignal.com/changelog/nodejs/2026-10-22-18-51-node.js-3.9.3](https://www.appsignal.com/changelog/nodejs/2026-10-22-18-51-node.js-3.9.3) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 root certificate, which those intermediates chain to. View the [Node.js package v3.9.3 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#393) for more information. --- ## Stop trusting compromised eMudhra certificates 2026-10-22 · Wrap · 0.3.3 · Security · [www.appsignal.com/changelog/wrap/2026-10-22-18-51-wrap-0.3.3](https://www.appsignal.com/changelog/wrap/2026-10-22-18-51-wrap-0.3.3) ## Security - Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were [compromised in October 2026](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). The bundled CA certificates no longer include the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, which those intermediates chain to. View the [Wrap v0.3.3 changelog](https://github.com/appsignal/appsignal-wrap/blob/main/CHANGELOG.md#033) for more information. --- ## Your Errors page filters are saved again 2026-10-22 · App · [www.appsignal.com/changelog/app/2026-10-22-errors-page-filters-saved](https://www.appsignal.com/changelog/app/2026-10-22-errors-page-filters-saved) The Errors page remembers your filters between visits again. Since October 1, it reset them each time you opened the page. Now the namespace, status, severity, assignee, sort order, and [revision](https://docs.appsignal.com/errors#see-the-errors-a-deploy-introduced) filters you set stay applied the next time you open the page in the same browser. Each app keeps its own filters. The search query is not saved. ![The Errors page with filters applied for app revision](/assets/changelog/2026-10/errors-page-saved-filters.png) Saved views work as before. Each one opens with the filters you saved in it. To keep a set of filters that includes a search query, [save it as a view](https://docs.appsignal.com/errors#filters-and-saved-views). Tell us what you think in our [Discord channel](https://discord.gg/jRnaSyDMkf). --- ## One MCP token for all your apps 2026-10-22 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-22-mcp-token-all-apps](https://www.appsignal.com/changelog/tools/2026-10-22-mcp-token-all-apps) Until now, an MCP token covered a fixed list of apps, so every new app meant creating a new token. MCP tokens can now cover all your apps, including apps you create later. When you create a token, select **All apps, including apps created later**. The token reaches every active app you have access to in the organization. AppSignal checks that list on each request, so your agent can use a new app without a new token. OAuth already works this way when you don't select any apps. ![The new MCP token form with All apps, including apps created later selected](/assets/changelog/2026-10/mcp-token-all-apps.png) To create a token, select your profile icon and go to **Account Settings → MCP Tokens**. Existing tokens keep their list of apps. To cover all apps, create a new token. The [MCP setup guide](https://docs.appsignal.com/mcp/setup#authentication) explains both ways to authenticate. Tell us what you think in our [Discord channel](https://discord.gg/jRnaSyDMkf). --- ## AppSignal MCP is now in Claude's connector directory 2026-10-20 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-20-mcp-claude-connector](https://www.appsignal.com/changelog/tools/2026-10-20-mcp-claude-connector) Until now, connecting AppSignal to Claude on the web or desktop meant configuring a custom connector. AppSignal is now listed in Claude's [connector directory](https://claude.ai/directory/appsignal), so you can add it from Claude's settings instead: 1. In Claude, go to **Settings → Customize/Connectors → Discover tab**. 2. Search for `AppSignal`. 3. Select **Connect**. 4. Authorize AppSignal. The [Claude app setup guide](https://docs.appsignal.com/mcp/setup#claude-app) walks you through each step. **Also new:** - **Charts in Claude and ChatGPT:** `get_metrics_timeseries` results render as an interactive AppSignal chart in hosts that support MCP Apps. In text-only clients, such as Claude Code and Cursor, your agent answers from the same data in Markdown. - **Uptime monitors:** `manage_uptime_monitor` creates, updates, and deletes uptime monitors. When a monitored URL is slow, your agent can show how long each step of the check took, such as the DNS lookup, the connection, and waiting for the server to respond. It gets these timings from the `uptime_monitor_timing` metric. - **Fewer round trips:** - `get_traces` filters traces by tag and looks up a trace by `trace_id` alone. - If you ask for logs over a longer period than one query can cover, `get_log_lines` returns the newest part and tells your agent which time range to request next, so it can keep reading back through your logs. - `get_incident` now shows the ID of each note on an incident, so your agent can update a note you wrote, instead of adding a new note. See the [MCP tool reference](https://docs.appsignal.com/mcp/reference) for every tool and parameter. Missing something? Ask your agent to call `get_more_tools`. We read those requests, and they shape what we add next. --- ## MCP tools return structured data you can use in code 2026-10-19 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-19-mcp-structured-output](https://www.appsignal.com/changelog/tools/2026-10-19-mcp-structured-output) `get_applications`, `get_metric_names`, `get_metric_tags`, and `get_metrics_list` now return structured data alongside their text output, as `get_metrics_timeseries` already does. Each tool declares an output schema, so MCP clients that run code can read typed fields, such as app names, metric tags, and values, instead of parsing Markdown. The text output is still there, so agents and clients that read it keep working without changes. **Also new:** - **Case-insensitive metric fields:** `get_metrics_list`, `get_metrics_timeseries`, and `manage_trigger` accept metric fields in any case, so `P90` works as well as `p90`. - **Fewer failed queries:** `get_metrics_list` no longer fails when you query without tags and the time range has no data. It reports that no data was found instead. See the [MCP tool reference](https://docs.appsignal.com/mcp/reference) for every tool and parameter. --- ## Changes to our upgrade policy 2026-10-19 · App · Announcement · [www.appsignal.com/changelog/app/2026-10-19-upgrade-policy-changes](https://www.appsignal.com/changelog/app/2026-10-19-upgrade-policy-changes) From December 1, 2026, going over your plan limit starts a 30-day usage review to determine whether a higher plan would better suit your usage. This replaces our previous upgrade process. We'll email your organization owners within a day of the usage review starting, check in on day 14, and email again if we extend the review or upgrade your plan. You'll always hear from us before your plan is upgraded. We'll continue monitoring your paid account without throttling or dropping data if you exceed your plan limit. We won't charge you for the overage itself. ## How a usage review works A usage review starts when you exceed your plan limit during a billing cycle. We review APM request usage and log storage separately, so exceeding your limit on one only starts a usage review for that plan. At the end of the 30-day usage review, we compare your usage over the last 30 days and the last 14 days with your plan limit. We convert both figures to a monthly equivalent: - If your 30-day usage is within your plan limit, the usage review closes with no change to your plan. - If both figures are over your plan limit, we automatically upgrade you to a plan that matches your usage. - If your 30-day usage is over your plan limit but your 14-day usage is within it, we extend the usage review by another 30 days. At day 60, we check your last 30 days of usage again. If it is still over your plan limit, we upgrade your plan. Otherwise, the usage review closes with no change. You'll stay on your current plan during the first 30 days. If your average usage over those 30 days is back within your plan, the usage review closes with no upgrade. ## If you're already in a usage review Usage reviews opened before December 1, 2026 follow the previous review policy, which required an upgrade if you exceeded your plan limit by more than 10% in at least two of the three most recent months. Usage reviews triggered from December 1, 2026 will follow our new usage review policy. ## Staying within your plan Our guides on [reducing requests](https://docs.appsignal.com/support/limiting-requests.html#ignore-actions) and [reducing log volume](https://docs.appsignal.com/support/billing/usage.html#reducing-your-logging) explain how to bring your usage back within your plan limit. You can also manually upgrade your plan at any time from your [Billing page](https://appsignal.com/redirect-to/organization?to=admin/plans/new). See our [upgrade policy](https://www.appsignal.com/upgrade-policy) for the full process and which accounts it applies to. If your usage pattern doesn't fit the policy well, [email us](mailto:support@appsignal.com) and we'll look at it with you. --- ## CLI v2.2.1 2026-10-15 · Tools (API, MCP, CLI) · 2.2.1 · [www.appsignal.com/changelog/tools/2026-10-15-05-45-cli-2.2.1](https://www.appsignal.com/changelog/tools/2026-10-15-05-45-cli-2.2.1) ## Changed - Stop sending and requesting the `severities` field for log views and log triggers. Severity filters are now part of the log query. `logs triggers create --severity` and `logs triggers update --severity` add the severities to the query as `severity=[...]`, and `logs triggers update --severity` now requires `--query`. The `logs triggers update --clear-severities` flag has been removed; edit the query instead. ## Fixed - Log searches and tails now handle JSON-encoded attribute strings without failing the entire result. Unstructured attribute strings are preserved in a raw field. View the [CLI v2.2.1 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#221) for more information. --- ## Ruby gem v5.0.5 2026-10-14 · Ruby · 5.0.5 · [www.appsignal.com/changelog/ruby/2026-10-14-11-28-ruby-5.0.5](https://www.appsignal.com/changelog/ruby/2026-10-14-11-28-ruby-5.0.5) ## Added - Automatically detect the application's revision from the `HEROKU_BUILD_COMMIT` environment variable, which is set by Heroku at runtime [when the `runtime-dyno-build-metadata` Heroku Labs feature](https://devcenter.heroku.com/articles/dyno-metadata) is enabled. ## Changed - Update appsignal dependency to 5.0.5. View the [Ruby gem v5.0.5 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#505) for more information. --- ## Elixir package v2.18.2 2026-10-14 · Elixir · 2.18.2 · [www.appsignal.com/changelog/elixir/2026-10-14-12-03-elixir-2.18.2](https://www.appsignal.com/changelog/elixir/2026-10-14-12-03-elixir-2.18.2) ## Added - Automatically detect the application's revision from the `HEROKU_BUILD_COMMIT` environment variable, which is set by Heroku at runtime [when the `runtime-dyno-build-metadata` Heroku Labs feature](https://devcenter.heroku.com/articles/dyno-metadata) is enabled. View the [Elixir package v2.18.2 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2182) for more information. --- ## Node.js package v3.9.2 2026-10-14 · Node.js · 3.9.2 · [www.appsignal.com/changelog/nodejs/2026-10-14-12-25-node.js-3.9.2](https://www.appsignal.com/changelog/nodejs/2026-10-14-12-25-node.js-3.9.2) ## Added - Automatically detect the application's revision from the `HEROKU_BUILD_COMMIT` environment variable, which is set by Heroku at runtime [when the `runtime-dyno-build-metadata` Heroku Labs feature](https://devcenter.heroku.com/articles/dyno-metadata) is enabled. ## Fixed - Improve handling of the extension internal queue when full. - Fix issues in the extension that lead to gaps in data reporting. - Fix an extension crash when the same span is used from multiple threads at the same time. View the [Node.js package v3.9.2 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#392) for more information. --- ## Python package v1.9.2 2026-10-14 · Python · 1.9.2 · [www.appsignal.com/changelog/python/2026-10-14-14-24-python-1.9.2](https://www.appsignal.com/changelog/python/2026-10-14-14-24-python-1.9.2) ## Added - Automatically detect the application's revision from the `HEROKU_BUILD_COMMIT` environment variable, which is set by Heroku at runtime [when the `runtime-dyno-build-metadata` Heroku Labs feature](https://devcenter.heroku.com/articles/dyno-metadata) is enabled. View the [Python package v1.9.2 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#192) for more information. --- ## Follow a failed browser request into your back end 2026-10-13 · App · [www.appsignal.com/changelog/app/2026-10-13-browser-distributed-tracing](https://www.appsignal.com/changelog/app/2026-10-13-browser-distributed-tracing) Browser monitoring can now report a failed request to your back end as an error in the trace it started. When a request returns a 5xx response or times out, it appears as an `HTTPError` or `TimeoutError`. Its trace timeline shows the back-end spans and errors beneath the browser's span. The service map connects the browser error to the back-end error behind it. ![A trace timeline linking an 85 ms browser HTTPError for GET /api/boom/ (HTTP 500) to an 81 ms django RuntimeError, with SELECT and POST child spans beneath it.](/assets/changelog/2026-10/browser-distributed-tracing-trace-timeline.png) ![A trace service map with two services, Browser and django, both marked with an error. The Browser box shows the /product/chocolate-stroopwafel route at 85 ms, connected by an 81 ms edge to GET api/boom/ in the django box.](/assets/changelog/2026-10/browser-distributed-tracing-service-map.png) Both the browser and your back end need setup. On the browser side, install `@appsignal/browser` 1.0.0-beta.7 with the `beta` tag. The [Browser SDK install flow](https://appsignal.com/redirect-to/organization?to=sites/new/browser) now offers **Distributed tracing** as an option. With only the browser side set up, you see the browser error without any back-end spans. Our documentation explains how to [set up both sides](https://docs.appsignal.com/browser/distributed-tracing). Distributed tracing is in beta as part of [AppSignal Labs](https://docs.appsignal.com/labs). Tell us what you think in our [Discord channel](https://discord.gg/EjF6ykYx63). --- ## Limits for high volume traces 2026-10-09 · Collector · 0.11.9 · [www.appsignal.com/changelog/collector/2026-10-09-08-54-collector-0.11.9](https://www.appsignal.com/changelog/collector/2026-10-09-08-54-collector-0.11.9) ## Fixed - Add limits to traces and span data to reduce the amount of data kept in memory during traffic burst and for long running traces. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Fix instrumentation issue on malformed request payloads 2026-10-09 · Ruby · 5.0.4 · [www.appsignal.com/changelog/ruby/2026-10-09-13-17-ruby-5.0.4](https://www.appsignal.com/changelog/ruby/2026-10-09-13-17-ruby-5.0.4) ## Fixed - Fix an issue where transactions would be reused across requests when an error happened before the transaction could be closed, which would lead to errors being returned by the app itself. ## Changed - Update appsignal dependency to 5.0.4. View the [Ruby gem v5.0.4 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#504) for more information. --- ## Fix cumulative metrics from forked processes 2026-10-08 · Ruby · 5.0.3 · [www.appsignal.com/changelog/ruby/2026-10-08-06-38-ruby-5.0.3](https://www.appsignal.com/changelog/ruby/2026-10-08-06-38-ruby-5.0.3) ## Fixed - In collector mode, report counter metrics correctly from processes forked after AppSignal starts, such as Puma workers when using `preload_app!`. Before this change, applications running several forked processes would lose data points or report incorrect values for them. ## Changed - Update appsignal dependency to 5.0.3. View the [Ruby gem v5.0.3 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#503) for more information. --- ## Page through metric lists with the Public API (V2) 2026-10-08 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-08-metrics-list-pagination](https://www.appsignal.com/changelog/tools/2026-10-08-metrics-list-pagination) `POST /api/v2/metrics/list` in the [Public API (V2)](https://docs.appsignal.com/api/v2/metrics) now supports pagination. Until now, a list query stopped at 1,000 series, and there was no way to fetch the rest. With pagination, you request the list in pages and continue until the last page. Pagination is optional. The response format stays the same, so existing integrations keep working without changes. Use it when a query matches more series than fit in one page. That usually means a custom metric with [high-cardinality tags](https://docs.appsignal.com/api/v2/metrics#high-cardinality-custom-metrics). The [Limits page](https://docs.appsignal.com/application/limits) in your app shows which custom metrics have the most unique keys. A paginated query that matches more than 100,000 metric keys returns an error instead of partial results. The [metrics API documentation](https://docs.appsignal.com/api/v2/metrics#page-through-a-list) describes the request format and shows an example. Timeseries queries work as before. [AppSignal MCP](https://docs.appsignal.com/mcp-server) uses the same endpoint, so your agent sees the same data as an unpaginated API request. If you still read metric lists through the deprecated GraphQL API, this is a good time to move. The [September changelog entry](https://www.appsignal.com/changelog/tools/2026-09-22-graphql-metrics-move-to-v2-api) explains why. Tell us what you think in our [Discord channel](https://discord.gg/jRnaSyDMkf). --- ## See where an uptime check spends its time 2026-10-08 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-10-08-uptime-monitor-request-timing](https://www.appsignal.com/changelog/tools/2026-10-08-uptime-monitor-request-timing) Uptime monitors now record how long each phase of a check took. The phases are DNS lookup, TCP connect, TLS handshake, time to first byte, body download, and the total. When a monitor is slow, you can see which phase is responsible: the lookup, the connection, or your server. The `uptime_monitor_timing` metric holds the timings, one value per phase and region. The app does not show them yet. Query them through the [Public API (V2)](https://docs.appsignal.com/api/v2/metrics#uptime-monitor-timings), or ask your agent through [AppSignal MCP](https://docs.appsignal.com/mcp/workflows#finding-where-an-uptime-check-spends-its-time). The [uptime monitoring documentation](https://docs.appsignal.com/uptime-monitoring/setup#request-timing) explains what each phase measures. Tell us what you think in our [Discord channel](https://discord.gg/jRnaSyDMkf). --- ## Collector v0.11.8 2026-10-07 · Collector · 0.11.8 · [www.appsignal.com/changelog/collector/2026-10-07-08-03-collector-0.11.8](https://www.appsignal.com/changelog/collector/2026-10-07-08-03-collector-0.11.8) ## Fixed - Improve the pruning of outdated sampling decisions. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Fix cumulative metrics from forked processes 2026-10-06 · Python · 1.9.1 · [www.appsignal.com/changelog/python/2026-10-06-12-16-python-1.9.1](https://www.appsignal.com/changelog/python/2026-10-06-12-16-python-1.9.1) ## Fixed - Metrics are reported correctly when several processes of your application send the same metric, including processes forked after AppSignal starts. Each process reports under a `service.instance.id` and a `process.pid` of its own, which is what AppSignal uses to tell them apart. View the [Python package v1.9.1 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#191) for more information. --- ## Prefer environment variables to the `REVISION` file 2026-10-06 · Ruby · 5.0.2 · [www.appsignal.com/changelog/ruby/2026-10-06-12-19-ruby-5.0.2](https://www.appsignal.com/changelog/ruby/2026-10-06-12-19-ruby-5.0.2) ## Changed - Use the revision set by Heroku, Render, Kamal or Scalingo when the application also has a `REVISION` file. Since version 4.6.0, a `REVISION` file took precedence over the `HEROKU_SLUG_COMMIT`, `RENDER_GIT_COMMIT`, `KAMAL_VERSION` and `CONTAINER_VERSION` environment variables, so an application that kept a placeholder `REVISION` file in source control reported that placeholder as its revision. The `revision` config option and the `APP_REVISION` environment variable still take precedence over both. Thanks to @rmm5t for their contribution! ## Changed - Update appsignal dependency to 5.0.2. View the [Ruby gem v5.0.2 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#502) for more information. --- ## Drop log lines after extracting metrics with one toggle 2026-10-06 · App · [www.appsignal.com/changelog/app/2026-10-06-drop-logs-after-extracting-metrics](https://www.appsignal.com/changelog/app/2026-10-06-drop-logs-after-extracting-metrics) Some log lines are worth counting but not worth storing. You could already keep the metric and drop the lines through AppSignal MCP, as the [MCP log processing workflow](https://docs.appsignal.com/mcp/workflows#setting-up-log-processing) shows. The app now does the same with one toggle.x Turn on **Drop log line after metric extraction** when you create or edit a log-based metric. AppSignal creates the filter action for you, directly after the metrics action, and keeps it in sync. You keep the metric, and AppSignal stops storing the lines, which reduces log storage costs for high-volume sources. On the **Metrics** page under Logging, metrics that drop their lines show **Drop after match** in the **Action** column. Log line actions only affect lines that arrive after you save them, and you cannot recover dropped lines. Check that the metric returns the data you expect before you turn the toggle on. Read the [documentation on dropping logs after extracting metrics](https://docs.appsignal.com/logging/drop-logs-after-extracting-metrics) for how the two actions run. Tell us what you think in our [Discord channel](https://discord.gg/jRnaSyDMkf). --- ## Fix reporting metrics from several processes 2026-10-02 · Collector · 0.11.7 · [www.appsignal.com/changelog/collector/2026-10-02-08-11-collector-0.11.7](https://www.appsignal.com/changelog/collector/2026-10-02-08-11-collector-0.11.7) ## Fixed - Report cumulative counter and histogram metrics correctly when several processes send a metric with the same name and attributes. Before this change, applications running several processes, such as web server workers, would lose data points or report incorrect values for them. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Fix allocations reporting in collector mode 2026-10-02 · Ruby · 5.0.1 · [www.appsignal.com/changelog/ruby/2026-10-02-08-14-ruby-5.0.1](https://www.appsignal.com/changelog/ruby/2026-10-02-08-14-ruby-5.0.1) ## Added - In collector mode, also report the `response_status` counter with a `service` tag. Response statuses can then be graphed per service when several services report to one app. ## Fixed - Improve handling of the extension internal queue when full. - Fix issues in the extension that lead to gaps in data reporting. - In collector mode, report allocation counts and queue durations per service and namespace. This fixes an issue where these metrics were reported by namespace alone, causing the "Performance" > "Allocations" page to link to performance pages that did not exist. ## Changed - Update appsignal dependency to 5.0.1. View the [Ruby gem v5.0.1 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#501) for more information. --- ## Improve logging support 2026-10-02 · Python · 1.9.0 · [www.appsignal.com/changelog/python/2026-10-02-08-27-python-1.9.0](https://www.appsignal.com/changelog/python/2026-10-02-08-27-python-1.9.0) ## Added - AppSignal warns when your application attaches the OpenTelemetry log handler from `opentelemetry.sdk._logs`, which is deprecated and is removed in a future release of the OpenTelemetry SDK. Its replacement is in `opentelemetry.instrumentation.logging.handler`. ## Changed - A log message that is not a string, such as the dictionary in `logger.info({"message": "Order placed", "order_id": 1234})`, is sent as text by the `logging` instrumentation. Pass the structured values in the `extra` argument to send a structured log line: ```python logger.info("Order placed", extra={"order_id": 1234}) ``` [The OpenTelemetry logs API](https://docs.appsignal.com/logging/integrations/python#sending-logs-with-opentelemetry) sends a structured log line from a dictionary body. ## Removed - AppSignal for Python no longer supports Python 3.8 and 3.9, requiring Python 3.10 or newer. ## Fixed - Ensure that data sent for check-ins, to an external collector, or via the agent always honors the `http_proxy` configuration option and the `APPSIGNAL_HTTP_PROXY` environment variable first, falling back to the `HTTP_PROXY` and `HTTPS_PROXY` environment variables if the configuration option is unset, and always ignores the `NO_PROXY` environment variable. - Fix local traffic to the AppSignal agent being incorrectly sent to an external proxy when the `http_proxy` configuration option is set in agent mode. - Improve handling of the extension internal queue when full. - Fix issues in the extension that lead to gaps in data reporting. - Logs are now still sent after your application configures the logging module. `logging.config.dictConfig()`, `logging.config.fileConfig()` and `logging.basicConfig()` keep AppSignal's log handler attached, so a configuration that sets its own handlers on the root logger, such as Django's `LOGGING` setting, will now send its logs to AppSignal as well. If you have manually added an OpenTelemetry log handler to your `LOGGING` setting or to the root logger elsewhere, it should now be removed, as AppSignal's handler will now send those log lines as well, causing them to be sent twice. AppSignal will log a warning when it detects a redundant OpenTelemetry handler. - When `disable_default_instrumentations` is used to disable the `logging` instrumentation, prevent the log lines emitted internally by AppSignal from propagating to a manually configured OpenTelemetry handler in the root logger. - `logging.basicConfig()` applies the log level it is given. An application that calls it with a level below `WARNING`, such as `logging.INFO`, starts sending its log lines at that level. - Fix an issue where AppSignal would configure redundant handlers when starting again in a forked process, such as when a Celery worker calls `appsignal.start()` from the `worker_process_init` signal. View the [Python package v1.9.0 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#190) for more information. --- ## Elixir package v2.18.1 2026-10-02 · Elixir · 2.18.1 · [www.appsignal.com/changelog/elixir/2026-10-02-11-37-elixir-2.18.1](https://www.appsignal.com/changelog/elixir/2026-10-02-11-37-elixir-2.18.1) ## Fixed - Report Broadway messages as parameters instead of as a `message` tag. View the [Elixir package v2.18.1 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2181) for more information. --- ## See only the errors a deploy introduced 2026-10-02 · App · [www.appsignal.com/changelog/app/2026-10-02-new-errors-filter](https://www.appsignal.com/changelog/app/2026-10-02-new-errors-filter) The **Pick a revision** filter on the errors page now lets you select **New errors** or filter errors "By Revision" or "By Timeframe". It lists the errors in most recent revisions, or only the errors first seen in the selected deploy or timeframe, so you can see exactly what a deploy broke and at what time. ![The Pick a revision filter open on the errors page, with New errors selected and a list of recent revisions](/assets/changelog/2026-10/error-filters.png) Open the filter, select **New errors**, and pick a scope: the most recent revisions, a specific revision, or a timeframe. While **New errors** is selected, the filter label says so, for example **New in revision a1b2c3d**. If you use [AppSignal MCP](https://docs.appsignal.com/mcp/setup), `get_exception_incidents` has a matching `new_only` parameter. Ask your agent which new errors your last deploy introduced, or which errors appeared since a point in time. Read the [errors docs](https://docs.appsignal.com/errors#see-the-errors-a-deploy-introduced) for how each scope counts new errors. --- ## Elixir package v2.18.0 2026-09-30 · Elixir · 2.18.0 · [www.appsignal.com/changelog/elixir/2026-09-30-17-12-elixir-2.18.0](https://www.appsignal.com/changelog/elixir/2026-09-30-17-12-elixir-2.18.0) ## Added - Automatically instrument Broadway library. [Broadway](https://elixir-broadway.org/) is an Elixir library for building concurrent and multi-stage data ingestion and data processing pipelines. When Broadway processes one or more messages, a trace is created to represent the processing of these messages. Independent root spans encompass the call to `prepare_messages/2` and `handle_message/3`. This instrumentation is enable by default and only available for Broadway versions higher than 1.0.0. View the [Elixir package v2.18.0 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2180) for more information. --- ## Performance traces now have a logbook 2026-09-30 · App · [www.appsignal.com/changelog/app/2026-09-30-performance-trace-logbook](https://www.appsignal.com/changelog/app/2026-09-30-performance-trace-logbook) Every action on the Traces page under Performance now has a logbook. One logbook holds the notes for all traces of an action. Traces expire, but notes stay with the action. Open an action from the Traces page and add a note in the **Logbook** section of its **Summary** tab. Notes support Markdown, and you can edit, pin, and delete them. The pinned note shows first. The **Logbook** tab shows the full logbook on its own page. Unlike a performance incident's logbook, whose notes have now moved to the trace logbook, our new trace logbook holds notes only. It does not record state changes or link GitHub issues. Notes on performance incidents now live in this logbook too. A performance incident's **Summary** and **Logbook** tabs link to the action's trace page. They keep showing the incident's activity, such as state changes. Existing notes are copied over, so they stay available after the incident closes and its traces expire. If you use the [AppSignal MCP server](https://docs.appsignal.com/mcp-server), the `manage_incident_note` tool is now `manage_note`. It adds and edits notes on incidents by number, and on performance trace actions by namespace and action name. The old tool name keeps working. Read the [trace page docs](https://docs.appsignal.com/trace-page) for what each trace shows. That page is also where [distributed tracing](https://docs.appsignal.com/distributed-tracing) shows its service map and timeline. Distributed tracing is in beta as part of [AppSignal Labs](https://docs.appsignal.com/labs). Tell us what you think of trace logbooks in our [Discord channel](https://discord.gg/EjF6ykYx63). --- ## Fix extension crashes on high traffic apps 2026-09-29 · Elixir · 2.17.7 · [www.appsignal.com/changelog/elixir/2026-09-29-07-04-elixir-2.17.7](https://www.appsignal.com/changelog/elixir/2026-09-29-07-04-elixir-2.17.7) ## Fixed - Fix an extension crash when the same span is used from multiple threads at the same time. View the [Elixir package v2.17.7 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2177) for more information. --- ## Fix missing dependency issue 2026-09-28 · Python · 1.8.1 · [www.appsignal.com/changelog/python/2026-09-28-09-57-python-1.8.1](https://www.appsignal.com/changelog/python/2026-09-28-09-57-python-1.8.1) ## Fixed - Fix an issue where AppSignal fails to start with `ModuleNotFoundError: No module named 'requests'` on Python 3.10 or later. View the [Python package v1.8.1 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#181) for more information. --- ## Collector mode release 2026-09-28 · Ruby · 5.0.0 · [www.appsignal.com/changelog/ruby/2026-09-28-13-29-ruby-5.0.0](https://www.appsignal.com/changelog/ruby/2026-09-28-13-29-ruby-5.0.0) ## Changed - Release the final package version. See the pre-release changelog entries for the changes in this version. View the [Ruby gem v5.0.0 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#500) for more information. --- ## Handle high data surges better 2026-09-28 · Elixir · 2.17.6 · [www.appsignal.com/changelog/elixir/2026-09-28-15-34-elixir-2.17.6](https://www.appsignal.com/changelog/elixir/2026-09-28-15-34-elixir-2.17.6) ## Fixed - Improve handling of the extension internal queue when full. - Fix issues in the extension that lead to gaps in data reporting. View the [Elixir package v2.17.6 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2176) for more information. --- ## Collector mode pre-release improvements 2026-09-23 · Ruby · 5.0.0.rc.2 · [www.appsignal.com/changelog/ruby/2026-09-23-13-29-ruby-5.0.0.rc.2](https://www.appsignal.com/changelog/ruby/2026-09-23-13-29-ruby-5.0.0.rc.2) This release also includes all the changes from AppSignal for Ruby version 4.10.4 and below. ## Added - Detect the revision that is being deployed from the environment variables set by Heroku, Render, Kamal and Scalingo: `HEROKU_SLUG_COMMIT`, `RENDER_GIT_COMMIT`, `KAMAL_VERSION` and `CONTAINER_VERSION`. Applications deployed on those platforms now report their revision without setting the `revision` configuration option. This affects collector mode, where deploys were reported as `unknown` when the revision was not configured. - Detect the hostname of the machine the application runs on. On Heroku this is the name of the dyno, and everywhere else it is the name the host reports for itself. Set the `hostname` configuration option to report a different name. This affects collector mode, where all data was reported for a host named `unknown` when the hostname was not configured. - Report the host, the port and the HTTP version of an incoming web request in collector mode. These are sent as the `server.address`, `server.port` and `network.protocol.version` OpenTelemetry attributes. The host is read from the `Forwarded` and `X-Forwarded-Host` headers when a proxy sets them, so it is the host the client used rather than the one the proxy connected to. - Report the request environment in collector mode. The `request_headers` configuration option is an allowlist of Rack environment names, and some of those names are not request headers. Those values are now reported as `appsignal.environment.*` OpenTelemetry attributes and shown in the request's Environment panel, instead of being left out. Values that describe the request itself are not repeated there, because they are already reported as the request's method, path, host, port and protocol version. - Add the `keep_request_headers` and `keep_request_environment` configuration options, which are used in collector mode. They replace `request_headers`, which is deprecated in collector mode. `keep_request_headers` lists the request headers to report, using the names OpenTelemetry uses for them, such as `accept` and `content-length`. `keep_request_environment` lists the Rack environment values to report that are not request headers, using the names Rack uses for them, such as `REMOTE_ADDR`. Both options default to a value derived from `request_headers`, which lists Rack environment keys and mixes the two kinds together. So an application that only ever set `request_headers` keeps reporting the same values when it moves to collector mode. The `request_headers` configuration option is deprecated in collector mode, and a warning will be emitted at startup, containing the values of `keep_request_headers` and `keep_request_environment` that should be used to replace it. In agent mode, `request_headers` still lists every Rack environment key to report, and the two new options have no effect. - Add the `Appsignal.add_request_headers` and `Appsignal.add_request_environment` helpers. Use `add_request_headers` to report request headers, naming each header in lowercase and with dashes, such as `content-length`. Use `add_request_environment` to report the values a Rack environment holds that are not request headers, naming each one the way Rack names it, such as `REMOTE_ADDR`. In agent mode, both write to the "Environment" sample data, formatted as Rack environment keys. In collector mode, they write different span attributes. Together they replace `Appsignal.add_headers`, which is now deprecated, as it accepts Rack environment keys and works out which ones are headers. - Report request headers for Webmachine applications. ## Changed - Report `app` instead of `unknown` as the OpenTelemetry service name when the `service_name` configuration option is not set and collector mode is in use. - The `filter_parameters` and `send_params` configuration options are deprecated in collector mode. Use `filter_request_payload`, `filter_function_parameters` and `filter_request_query_parameters` to filter different kinds of parameters, and `send_request_payload`, `send_request_query_parameters` and `send_function_parameters` to choose which kinds of parameters to report. In collector mode, each kind of parameter is now filtered and reported according to its own options, and the deprecated options' values are only used to fill in values when the new options are unset. AppSignal logs which values to set to keep reporting what it reports now. In agent mode, `filter_parameters` and `send_params` still apply to every kind of parameter, and the new options have no effect. ## Fixed - The `ignore_logs` option now filters out the log lines that match its patterns in collector mode. - In collector mode, backtrace lines from your own application are now shown as paths relative to your application's root, and are recognized as your application's code. - The `ca_file_path` and `http_proxy` options now apply to the data sent to the collector in collector mode. Before this change they only applied to the data sent by the agent, so a custom certificate authority file or a proxy had no effect in collector mode. - Remove an incorrect warning about the `filter_metadata` configuration option being ignored in collector mode. - Report request headers in collector mode. - Report no response headers in collector mode until the `response_headers` configuration option names some. The option had no effect at all, so every response header captured by the application's own OpenTelemetry instrumentation was reported whatever the option said. - Read an array configuration option written as a null in `config/appsignal.yml` as the empty list it means. Options such as `filter_parameters` and `ignore_actions` raised a `NoMethodError` when AppSignal started, and `filter_metadata` and `filter_session_data` raised one while a transaction was sampled. ## Changed - Update appsignal dependency to 5.0.0.rc.2. View the [Ruby gem v5.0.0.rc.2 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#500rc2) for more information. --- ## Collector mode fixes and improvements 2026-09-23 · Python · 1.8.0 · [www.appsignal.com/changelog/python/2026-09-23-13-43-python-1.8.0](https://www.appsignal.com/changelog/python/2026-09-23-13-43-python-1.8.0) ## Added - Add the `set_request_payload`, `set_request_query_parameters` and `set_function_parameters` helpers. Each one reports a kind of parameters that collector mode keeps apart, so the option that filters that kind, and the one that suppresses it, apply to what you report: ```python from appsignal import set_function_parameters set_function_parameters({"user_id": 123}) ``` In collector mode, the `set_params` helper is now deprecated, and it reports the request payload. It does not say which kind of parameters it is given, so use `set_request_payload`, `set_request_query_parameters` or `set_function_parameters` instead. AppSignal warns the first time it is used. In agent mode there is one place to report parameters, so all four helpers report to it, the last one called is the one that takes effect, and `set_params` is not deprecated. - Report the response headers listed in the `response_headers` configuration option when a collector is used. ## Changed - The `filter_parameters` and `send_params` configuration options are deprecated in collector mode. Use `filter_request_payload`, `filter_function_parameters` and `filter_request_query_parameters` to filter different kinds of parameters, and `send_request_payload`, `send_request_query_parameters` and `send_function_parameters` to choose which kinds of parameters to report. AppSignal warns about the deprecated options at startup, and names the value to set for each option that replaces them. In agent mode, `filter_parameters` and `send_params` still apply to every kind of parameter, and the new options have no effect. - In collector mode, the `filter_request_payload`, `filter_function_parameters` and `filter_request_query_parameters` configuration options now fall back to the value of `filter_parameters`, and the `send_request_payload`, `send_request_query_parameters` and `send_function_parameters` options fall back to the value of `send_params`. An application that filtered parameters or turned parameter reporting off keeps doing so after it switches to a collector, without having to set the new options. Setting one of the new options still overrides the value that would be derived for it. - The `appsignal diagnose` report now names where each configuration option's value came from. An option set from more than one source lists the value from each source. - In collector mode, the Django and Flask instrumentation now reports a request's query string as query parameters rather than as a request payload. So `filter_request_query_parameters` and `send_request_query_parameters` apply to a query string, and `filter_request_payload` and `send_request_payload` apply to a Django request's body. In agent mode, a Flask application's query parameters are now reported on their own, rather than nested under an `args` key. ## Fixed - Report a request or response header whose name is written with capital letters or underscores in the `request_headers` or `response_headers` configuration option, such as `Content-Type` or `content_type`. The collector matches these names against the ones it receives the headers under, which follow the OpenTelemetry semantic convention: the header's own name, lowercased, with its dashes kept. A name written any other way matched nothing, so the header was left out. The `set_header` helper names a header the same way when a collector is in use. View the [Python package v1.8.0 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#180) for more information. --- ## Changes to the free plan 2026-09-23 · App · Announcement · [www.appsignal.com/changelog/app/2026-09-23-free-plan-request-limit](https://www.appsignal.com/changelog/app/2026-09-23-free-plan-request-limit) Our free plan's request limit drops from 50K to 30K requests per month. The 30K limit applies to new free plan accounts, and to any account that moves to a paid plan and later returns to free. Our 1GB logging and 5-day retention limits stay the same. Every AppSignal feature stays available on the free plan until your app goes over the request or logging limit. Past that point, AppSignal locks access to the AppSignal app UI and the API, and disables notifications. ## If you're already on the free plan You keep your current limits until October 31, 2026. That gives you two options: - **Stay on the free plan.** Your limit becomes 30K requests per month. - **Move to a paid plan.** Paid plans start at 250K requests per month. Compare them on our [pricing page](https://www.appsignal.com/plans). Move to a paid plan before October 31, 2026 and get 25% off your first year. Email [support@appsignal.com](mailto:support@appsignal.com) for details on the promotion. Check your request usage on the **Billing** page in your organization settings. Not sure which plan fits your app? [Email us](mailto:support@appsignal.com), and we'll help you pick one. --- ## Delegate adding applications to an agent 2026-09-23 · App · [www.appsignal.com/changelog/app/2026-09-23-set-up-with-ai](https://www.appsignal.com/changelog/app/2026-09-23-set-up-with-ai) We now provide a new provisioning endpoint and prompts to enable you to delegate adding an application to any LLM of your choice. Select **Add an app** and choose the **Set up with AI** path to find the instructions for your agent. Read more in [our documentation](https://docs.appsignal.com/guides/install-with-agents). ![The Add an app page, with two cards side by side: Set up with AI, badged New, and Set up by hand. Each lists three steps and a button, Use your coding agent or Walk me through it.](/assets/changelog/2026-09/add-an-app.png) --- ## Fix AppSignal starting after Rails configuration initializers 2026-09-22 · Ruby · 4.10.4 · [www.appsignal.com/changelog/ruby/2026-09-22-13-03-ruby-4.10.4](https://www.appsignal.com/changelog/ruby/2026-09-22-13-03-ruby-4.10.4) ## Fixed - Start AppSignal before the Rails application's initializers run. Depending on the order in which gems were loaded, AppSignal could start after `config/initializers`. In those applications `Appsignal.active?` returned `false` inside an initializer, errors raised by initializers were not reported, and with `config.appsignal.start_at = :after_initialize` the Rails defaults for `log_path` and `ignore_actions` were not applied. View the [Ruby gem v4.10.4 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4104) for more information. --- ## Fix request header filtering and other improvements 2026-09-22 · Collector · 0.11.6 · [www.appsignal.com/changelog/collector/2026-09-22-20-11-collector-0.11.6](https://www.appsignal.com/changelog/collector/2026-09-22-20-11-collector-0.11.6) ## Fixed - Use case-insensitive comparison when filtering request and response headers (`http.request.header.*` and `http.response.header.*` span attributes) using the values in the `appsignal.config.request_headers` and `appsignal.config.response_headers` resource attribute configuration options. - Keep reporting a request's path when the `appsignal.config.send_request_query_parameters` resource attribute configuration option is set to `false`. The `url.full` and `http.target` span attributes now lose their query string rather than being removed, because they hold the request path as well. Applications whose instrumentation reports the path in `http.target`, without also reporting an `http.route` attribute, showed no path on their samples and error incidents. - Report request and response headers in lowercase and using dashes as separators, following the current OpenTelemetry semantic conventions. The values in the lists of allowed header names in the `appsignal.config.request_headers` and `appsignal.config.response_headers` resource attribute configuration options are also normalized to this shape before comparison. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Distributed tracing, now in beta 2026-09-22 · App · Beta · [www.appsignal.com/changelog/app/2026-09-22-distributed-tracing-beta](https://www.appsignal.com/changelog/app/2026-09-22-distributed-tracing-beta) Follow one request across every service it touches, including the background job your web request just enqueued. Now in beta for Ruby, Python, and PHP. We've added a service map and updated the trace timeline on the trace detail page. **The service map** shows a trace from the perspective of the services that took part: which services the request reached, and how long each call between them took. Edges are colored by how each call rates against the trace's own baseline, so the slowest calls stand out without you reading every duration. It appears once a trace crosses more than one service. ![A trace service map for one checkout request. The gateway service calls pricing, inventory, payments and fulfillment, which call on to catalog, notifications and courier. Every call is labeled by duration and colored green for fast or red for critical. Dashed edges link to a ledger service and a RabbitMQ job in another trace.](/assets/changelog/2026-09/trace-service-map.png) Above: one checkout across nine services. The dashed lines show work linked from another trace. **The updated trace timeline** lays every span out over time, including spans that came from a different service, so you can see where the time went. ![A trace timeline showing a request's spans laid out over time, spanning three services, with the attributes of the selected span in a side panel.](/assets/changelog/2026-09/trace-timeline.png) To turn it on, point `collector_endpoint` at a hosted collector and give each app its own `service_name`. PHP and custom OpenTelemetry setups already report through a collector, so there's nothing to switch on. Ruby also needs the AppSignal for Ruby 5.0 pre-release and the `appsignal-opentelemetry` gem. Elixir and Node.js aren't supported yet. Read the [distributed tracing docs](https://docs.appsignal.com/distributed-tracing) to set it up, or the [Ruby specifics](https://docs.appsignal.com/ruby/distributed-tracing) for the integrations that carry the trace for you. Part of [AppSignal Labs](https://docs.appsignal.com/labs). --- ## Read metric data with the Public API (V2), not GraphQL 2026-09-22 · Tools (API, MCP, CLI) · Breaking change · [www.appsignal.com/changelog/tools/2026-09-22-graphql-metrics-move-to-v2-api](https://www.appsignal.com/changelog/tools/2026-09-22-graphql-metrics-move-to-v2-api) If you read metric data through the GraphQL API, move those queries to the [Public API (V2)](https://docs.appsignal.com/api/v2/metrics). The GraphQL `app.metrics` fields read only our MongoDB metric store, and a growing share of metrics is now stored in ClickHouse. Uptime monitoring moved to ClickHouse on July 21, 2026. Since then, `uptime_monitor_duration`, `uptime_monitor_error_count`, and `days_until_ssl_expiration` return nothing over GraphQL: `app.metrics.keys` returns zero keys, and `app.metrics.timeseries` returns the correct timestamps with an empty `values` array. Neither raises an error, so the gap is easy to miss. Your monitoring is unaffected. Checks still run, and dashboards, triggers, and status pages read from ClickHouse directly. Only reads through the GraphQL metric fields are affected. Host metrics and Kubernetes metrics are served the same way, so GraphQL doesn't return those either. Metrics reported by our integrations — throughput, response times, error counts, Apdex, and your own custom metrics — are unchanged and still available over GraphQL. Here's where to send metric queries instead: - `app.metrics.keys` → `GET /api/v2/metrics/names/{site_id}` - `app.metrics.timeseries` → `POST /api/v2/metrics/timeseries` - `app.metrics.list` → `POST /api/v2/metrics/list` The metric names stay the same, as do the `name` and `region` tags on uptime metrics. Uptime metrics also gained an `id` tag holding the monitor's ID, so you can query one monitor across a rename. Both APIs authenticate with your personal API token, so you don't need new credentials. GraphQL stays the API for models and configuration: apps, incidents, dashboards, alerts, uptime monitors, and check-ins. If an agent reads this data for you, [AppSignal MCP](https://docs.appsignal.com/mcp-server) already queries the V2 endpoints. --- ## MCP: check-in monitors, incident search, and deeper traces 2026-09-22 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-09-22-mcp-check-ins-search-traces](https://www.appsignal.com/changelog/tools/2026-09-22-mcp-check-ins-search-traces) AppSignal MCP now covers check-in monitors, searches incidents by keyword, and returns more from your logs and traces. Your agent can triage more deeply without switching back to the AppSignal UI. **What's new:** - **Check-in monitors:** Ask whether last night's export ran, and which runs were missed or late. Set up a monitor for a new cron job without leaving your editor. `get_check_in_triggers` and `manage_check_in_trigger` cover both cron and heartbeat monitors. - **Incident search:** Ask for the errors you're chasing by name, instead of having your agent page through incidents to find them. `get_exception_incidents` takes a `query` parameter that matches exception and action names, case-insensitively, with `*` wildcards. - **Full log messages:** Stack traces, JSON payloads, and long error strings now arrive intact. `get_log_lines` keeps the 120-character preview as the heading, then adds the full message below it, up to 2,000 characters. - **Deeper trace detail:** One call now shows where a slow request spent its time. `get_traces` tree mode includes the root span and a duration breakdown of self time per category. Database query text comes through up to 10,000 characters, up from 500, so your agent can read the N+1 or the missing index in full. We also consolidated three tools, which keeps the toolset short and leaves more of your agent's context free. `archive_trigger` moved into `manage_trigger`, and `reorder_log_line_actions` and `delete_log_line_action` moved into `manage_log_line_action`. Each now takes an `action` parameter. The old names still work as aliases, so existing prompts keep working. A fix to the `server/discover` handshake clears most of the "Method not found" errors clients were hitting. Missing something? Ask your agent to call `get_more_tools`. We read those requests, and they shape what we add to MCP next. See the [MCP tool reference](https://docs.appsignal.com/mcp/reference) for the full list of tools and parameters. --- ## Handle incidents from the Slack message 2026-09-22 · App · [www.appsignal.com/changelog/app/2026-09-22-slack-modern](https://www.appsignal.com/changelog/app/2026-09-22-slack-modern) The Slack app is newly rearchitected, with two-way sync. It joins the other beta features in [AppSignal Labs](https://docs.appsignal.com/labs). From an error or performance incident notification you can: - **Close or reopen the incident** — the message rewrites itself to show the new state and who changed it. - **Change assignees** — pick from your team without switching to AppSignal. - **Set severity** — from the same message. Sync runs both ways. Close an incident in the AppSignal UI and the Slack notification that announced it is edited to match. Add **Slack Modern** from **Add integration** on the Notifications page. Read the [Slack integration docs](https://docs.appsignal.com/application/integrations/slack#slack-modern) for setup and for migrating an existing Slack notifier, and tell us how it goes in our [Discord](https://discord.gg/EjF6ykYx63). --- ## Apdex, now in preview 2026-09-16 · App · Beta · [www.appsignal.com/changelog/app/2026-09-16-apdex](https://www.appsignal.com/changelog/app/2026-09-16-apdex) Apdex (Application Performance Index) turns your response times into a single score between 0 and 1, so you can see at a glance how satisfied your users are with your app's performance. You can set satisfied and tolerating thresholds per namespace, and AppSignal scores every request against thresholds. You get an Apdex page under Performance, plus `apdex` and `apdex_counts` metrics you can use on your own dashboards and in anomaly detection triggers. Apdex is part of [AppSignal Labs](https://docs.appsignal.com/labs). Every organization has access to it. Read the [Apdex documentation](https://docs.appsignal.com/metrics/apdex) to set your thresholds, and tell us about it in our [Discord channel](https://discord.gg/EjF6ykYx63). --- ## Chart zoom now rescales the y axis 2026-09-16 · App · [www.appsignal.com/changelog/app/2026-09-16-chart-zoom](https://www.appsignal.com/changelog/app/2026-09-16-chart-zoom) Select an area on a chart to zoom into it. Charts now zoom on the time axis only, and the y axis rescales to fit the data in that range. Before, a selection scaled both axes at once, so a zoomed range could still sit flat against the original y scale. Now the detail you selected fills the chart, and the axis values animate as they change. Sparklines on vital cards no longer zoom. --- ## Stage changes for dark mode and log-based metrics 2026-09-16 · App · [www.appsignal.com/changelog/app/2026-09-16-labs-stage-changes](https://www.appsignal.com/changelog/app/2026-09-16-labs-stage-changes) Two features we announced earlier this year have changed stage. **Dark mode is now generally available.** It has left [AppSignal Labs](https://docs.appsignal.com/labs) and is available to everyone. Light mode remains the default. To opt in, select your profile picture and switch the **Theme** toggle to **Dark**, or to **System** to follow your OS preference. **Log-based metrics is now in preview.** It stays in Labs. Preview features are self-serve, so turn it on yourself and tell us how it goes in our [Discord channel](https://discord.gg/EjF6ykYx63). [Read about the Labs stages](https://docs.appsignal.com/labs) --- ## AppSignal MCP is now generally available 2026-09-16 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-09-16-mcp-general-availability](https://www.appsignal.com/changelog/tools/2026-09-16-mcp-general-availability) Our hosted MCP endpoint at `https://appsignal.com/api/mcp` leaves preview and is now generally available. Agents connect to it directly, so there's no server to install or run. Point your agent at it for read and write access across seven areas: error incidents, performance, anomaly detection, logging, metrics, dashboards, and app discovery. Authenticate with OAuth, or with an MCP token scoped per toolset and application. Setup instructions cover Claude Code, the Claude app, Cursor, Devin, Zed, VS Code, GitHub Copilot CLI, Gemini CLI, and OpenAI Codex. The Docker image enters maintenance mode as of September 16, 2026. If you still run [`appsignal-mcp`](https://github.com/appsignal/appsignal-mcp) locally, we recommend moving to the hosted endpoint. Read the [MCP documentation](https://docs.appsignal.com/mcp-server) to get set up. --- ## Add `is_active` attribute 2026-09-15 · Python · 1.7.2 · [www.appsignal.com/changelog/python/2026-09-15-15-04-python-1.7.2](https://www.appsignal.com/changelog/python/2026-09-15-15-04-python-1.7.2) ## Added - Add an `is_active` attribute to the AppSignal client. It tells you whether AppSignal is configured to start, so you can use it to only run code that makes sense when AppSignal is active: ```python from appsignal import Appsignal appsignal = Appsignal(name="My app name", push_api_key="my-push-api-key", active=True) if appsignal.is_active: # Only runs when AppSignal is active ``` Before this change, the only way to check this was to read the client's private configuration object. View the [Python package v1.7.2 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#172) for more information. --- ## Elixir package v2.17.5 2026-09-10 · Elixir · 2.17.5 · [www.appsignal.com/changelog/elixir/2026-09-10-08-43-elixir-2.17.5](https://www.appsignal.com/changelog/elixir/2026-09-10-08-43-elixir-2.17.5) ## Changed - Update the agent to handle high traffic apps. On high-traffic apps that would exceed the maximum accepted internal payload size, send data to the Push API more frequently. ## Fixed - Fix the sanitization of function arguments in SQL statements. Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list. View the [Elixir package v2.17.5 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2175) for more information. --- ## Node.js package v3.9.1 2026-09-10 · Node.js · 3.9.1 · [www.appsignal.com/changelog/nodejs/2026-09-10-10-20-node.js-3.9.1](https://www.appsignal.com/changelog/nodejs/2026-09-10-10-20-node.js-3.9.1) ## Fixed - Fix the sanitization of function arguments in SQL statements. Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list. View the [Node.js package v3.9.1 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#391) for more information. --- ## CLI v2.2.0 2026-09-10 · Tools (API, MCP, CLI) · 2.2.0 · [www.appsignal.com/changelog/tools/2026-09-10-13-14-cli-2.2.0](https://www.appsignal.com/changelog/tools/2026-09-10-13-14-cli-2.2.0) ## Added - Add dashboard chart inspection, creation, and partial updates from JSON files or stdin. Creating dashboards and charts now requires a nonempty description. Partial updates continue to preserve omitted descriptions. ## Fixed - Fix dashboard commands rejecting valid API source values. - Restore exception details and ordered error causes in incidents show using retained traces. Cause backtrace locations remain available. If optional details cannot be loaded within ten seconds, the command preserves available results and warns on stderr without failing. - Structured metadata from JSON logs is now included in both JSON and human output from logs search and logs tail. View the [CLI v2.2.0 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#220) for more information. --- ## Ruby gem v4.10.3 2026-09-10 · Ruby · 4.10.3 · [www.appsignal.com/changelog/ruby/2026-09-10-16-00-ruby-4.10.3](https://www.appsignal.com/changelog/ruby/2026-09-10-16-00-ruby-4.10.3) ## Fixed - Fix the sanitization of function arguments in SQL statements. Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list. View the [Ruby gem v4.10.3 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4103) for more information. --- ## Support Grape 4 and other improvements 2026-09-09 · Ruby · 4.10.2 · [www.appsignal.com/changelog/ruby/2026-09-09-11-05-ruby-4.10.2](https://www.appsignal.com/changelog/ruby/2026-09-09-11-05-ruby-4.10.2) ## Added - Add support for Grape 4. On Grape 4, every request through a Grape API raised a `NoMethodError`. Applications on Grape 3 and below were not affected. On Grape 4, the action name and the reported path now describe the endpoint's full route, so they include the API prefix, the path version and the mount point. They also no longer end in a trailing slash when the endpoint declares no path of its own, so an endpoint reported as `GET::My::Api#/users/:id/` is now reported as `GET::My::Api#/users/:id`. Action names on Grape 3 and below do not change. ## Changed - Update the agent to handle high traffic apps. On high-traffic apps that would exceed the maximum accepted internal payload size, send data to the Push API more frequently. ## Fixed - Load the host Rails application before the `appsignal demo` command reads the AppSignal configuration. This matches the behavior of `appsignal diagnose`. Thanks [@Guflly](https://github.com/Guflly) for your contribution! - Fix events showing as unknown in long-running applications. An application process that kept running for thirty days without restarting could lose the names and queries of the events it recorded, both in slow traces and in the "Slow events" panel. - Prevent `gc` events from appearing in the "Slow events" panel. - Report Delayed Job jobs that fail to load. Before this change, a job whose payload could not be deserialized was not reported to AppSignal at all. This can happen when a deploy removes or renames a job class while jobs of that class are still queued. Those jobs are now reported as failed, with the `Delayed::DeserializationError` they raised, and are named after the class recorded in the job's handler. When even that cannot be read, they are named `DelayedJobInternal`. - Record a single event for a bulk enqueue of Active Job jobs. Before this change, enqueuing jobs with `ActiveJob.perform_all_later` would record an event for the batch and, if the adapter was instrumented with AppSignal, another event for each job in it. A job that slices a large collection and enqueues it in batches was therefore reported with an event per job enqueued, where before version 4.9.0 it had one event per batch. A bulk enqueue is now recorded as a single `enqueue_all.active_job` event, named after the job class when every job in the batch shares one. View the [Ruby gem v4.10.2 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4102) for more information. --- ## Update the agent in the 3.x series 2026-09-09 · Ruby · 3.13.2 · [www.appsignal.com/changelog/ruby/2026-09-09-11-28-ruby-3.13.2](https://www.appsignal.com/changelog/ruby/2026-09-09-11-28-ruby-3.13.2) ## Changed - Update the agent to handle high traffic apps. On high-traffic apps that would exceed the maximum accepted internal payload size, send data to the Push API more frequently. - Update the agent from version 0.35.19 to version 0.37.0. The 3.x series of the Ruby gem was several agent releases behind, so this update also brings the improvements from every agent release in between. Those include better sanitisation of SQL queries, host metric collection that keeps working when a disk mount is frozen, and no more leftover `[timeout]` processes on Alpine Linux containers. ## Fixed - Fix events showing as unknown in long-running applications. An application process that kept running for thirty days without restarting could lose the names and queries of the events it recorded, both in slow traces and in the "Slow events" panel. - Prevent `gc` events from appearing in the "Slow events" panel. View the [Ruby gem v3.13.2 changelog](https://github.com/appsignal/appsignal-ruby/blob/3.x-stable/CHANGELOG.md#3132) for more information. --- ## Python package v1.7.1 2026-09-09 · Python · 1.7.1 · [www.appsignal.com/changelog/python/2026-09-09-14-21-python-1.7.1](https://www.appsignal.com/changelog/python/2026-09-09-14-21-python-1.7.1) ## Fixed - Fix the sanitization of function arguments in SQL statements. Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list. View the [Python package v1.7.1 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#171) for more information. --- ## Support host metrics in collector mode 2026-09-08 · Python · 1.7.0 · [www.appsignal.com/changelog/python/2026-09-08-10-41-python-1.7.0](https://www.appsignal.com/changelog/python/2026-09-08-10-41-python-1.7.0) ## Added - Add an `ignore_logs` option, which takes a list of patterns. Log lines that match any of the patterns are not sent to AppSignal. Set it with the `APPSIGNAL_IGNORE_LOGS` environment variable, or as an option on the `Appsignal` client. Read our [ignore logs guide](https://docs.appsignal.com/guides/filter-data/ignore-logs.html) for the patterns that are supported. This option only has an effect in collector mode, because that is the only mode in which this package sends logs. - Report host metrics, NGINX metrics, StatsD metrics and environment metadata when using a collector. These are sent by the AppSignal agent, which now runs alongside the collector instead of being replaced by it. - Detect the revision that is being deployed from the environment variables set by Heroku, Render, Kamal and Scalingo: `HEROKU_SLUG_COMMIT`, `RENDER_GIT_COMMIT`, `KAMAL_VERSION` and `CONTAINER_VERSION`. Applications deployed on those platforms now report their revision without setting the `revision` configuration option. This affects collector mode, where deploys were reported as `unknown` when the revision was not configured. ## Changed - Report `app` instead of `unknown` as the OpenTelemetry service name when the `service_name` configuration option is not set and collector mode is in use. - On Heroku, report the name of the dyno as the hostname. Before, the hostname of the container that the dyno runs in was reported, so applications running on Heroku will see their data reported under a new host name. - Update the agent to handle high traffic apps. On high-traffic apps that would exceed the maximum accepted internal payload size, send data to the Push API more frequently. ## Fixed - An option set to `None` when initializing the `Appsignal` client no longer replaces a value that AppSignal detected itself. For example, `Appsignal(hostname=None)` now reports the detected hostname, instead of reporting no hostname at all. Options that AppSignal does not detect are unchanged: setting `request_headers` to `None`, for example, still turns off request header collection. - In collector mode, backtrace lines from your own application are now shown as paths relative to your application's root, and are recognized as your application's code. - Send the traces, metrics and logs that are still buffered when `stop` is called, instead of dropping them. - Apply the `ca_file_path` and `http_proxy` configuration options to the data sent to a collector. Before this change both options were only applied to the data sent by the agent, so a custom certificate authority file or a proxy had no effect when a collector was used. - Stop running minutely probes when `stop` is called. Before this change they kept running and kept reporting metrics after AppSignal was stopped. View the [Python package v1.7.0 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#170) for more information. --- ## Support BullMQ 6 and update OpenTelemetry dependencies 2026-09-08 · Node.js · 3.9.0 · [www.appsignal.com/changelog/nodejs/2026-09-08-10-47-node.js-3.9.0](https://www.appsignal.com/changelog/nodejs/2026-09-08-10-47-node.js-3.9.0) ## Added - Report queue events from applications that use BullMQ's own telemetry, which is what BullMQ version 6 and newer offer through the `bullmq-otel` package. These were previously reported as uncategorised events named after the raw span, because BullMQ describes its spans with its own attributes rather than the OpenTelemetry messaging conventions. They are now named and categorised the same way as events from the `@appsignal/opentelemetry-instrumentation-bullmq` package. - Warn when your application loads more than one version of `@opentelemetry/api`, warning about potential data loss, as older versions fail to send data through global values configured by newer versions. The warning names the versions and where they were loaded from. ## Changed - Update the bundled OpenTelemetry packages to their current versions. This resolves two reported vulnerabilities: - CVE-2026-59892 in `@opentelemetry/propagator-jaeger`, which this integration does not use but did bundle through `@opentelemetry/sdk-node`. - CVE-2026-54285 in `@opentelemetry/core`, which applies to the W3C baggage propagation that this integration does use. - Update the agent to handle high traffic apps. On high-traffic apps that would exceed the maximum accepted internal payload size, send data to the Push API more frequently. - Allow any 1.x version of `@opentelemetry/api` from 1.9.0 onwards. This prevents an issue where npm installs a second copy of the package for AppSignal alone, which can stop spans from being reported without any error. ## Removed - Drop support for Node.js 18. The minimum supported version is now Node.js 20.6.0, which is what the bundled OpenTelemetry packages require. ## Fixed - Keep naming MongoDB events after the operation they perform when the `@opentelemetry/instrumentation-mongodb` package is version 0.74.0 or newer. That version renames its spans to follow the stable database semantic conventions, and events from it were being named `unknown.mongodb` as a result. - Report the queue name on BullMQ events as the `queue` tag. It was being reported as the `message_destination` tag instead. - Do not emit B3 trace context propagation headers. If you relied on AppSignal to send the trace context in the `b3` or `x-b3-*` headers, you can configure that yourself by passing your own `textMapPropagator` to the OpenTelemetry SDK. View the [Node.js package v3.9.0 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#390) for more information. --- ## Fix the sanitization of function arguments in SQL statements 2026-09-07 · Collector · 0.11.5 · [www.appsignal.com/changelog/collector/2026-09-07-15-53-collector-0.11.5](https://www.appsignal.com/changelog/collector/2026-09-07-15-53-collector-0.11.5) ## Fixed - Fix the sanitization of function arguments in SQL statements. Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list. Now the collector correctly sanitizes function arguments. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Improve internal metrics reporting 2026-09-04 · Collector · 0.11.4 · [www.appsignal.com/changelog/collector/2026-09-04-10-39-collector-0.11.4](https://www.appsignal.com/changelog/collector/2026-09-04-10-39-collector-0.11.4) ## Changed - Improve internal metrics reporting. The collector now reports additional internal metrics about trace processing. These metrics are used by AppSignal to monitor the collector. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Logs query autocomplete, now generally available 2026-09-03 · App · [www.appsignal.com/changelog/app/2026-09-03-logs-query-autocomplete](https://www.appsignal.com/changelog/app/2026-09-03-logs-query-autocomplete) Logs query autocomplete is now generally available to all customers. It suggests fields, operators, severity values, and join operators as you build a query, so you can select from a list instead of remembering the syntax. ![Logs query bar with three applied filters and a dropdown of fields and attributes](/assets/changelog/2026-09/logs-query-autocomplete.png) Select the query bar and a dropdown opens with two groups: - **Fields** are available on every log line: severity, hostname, group, and message. - **Attributes** are the keys AppSignal finds in your own JSON log lines, such as `code.file.path` or `data.args`. Select a field, then an operator, and then a value. The operators are **is**, **is not**, **contains**, and **does not contain**. For severity queries, AppSignal also suggests values such as `error`, `warning`, and `info`. You can still type or paste a full query. AppSignal keeps the query as editable text while you build it. The same autocomplete is now available in the query fields for log triggers and log metrics. In the metrics form, suggestions also include fields available for metric extraction and grouping. ![Logs query bar containing autocomplete field suggestions and preselected log source values in the log metrics form](/assets/changelog/2026-09/trigger-metric-autocomplete.png) Try it the next time you filter your logs, create a log trigger, or define a log metric, and tell us how it goes on our [Discord server](https://discord.gg/sBWWGwYzfC). Read the [query syntax documentation](https://docs.appsignal.com/logging/query-syntax) for the syntax behind the editor. --- ## Fix host metrics and query sanitization 2026-09-01 · Collector · 0.11.3 · [www.appsignal.com/changelog/collector/2026-09-01-10-41-collector-0.11.3](https://www.appsignal.com/changelog/collector/2026-09-01-10-41-collector-0.11.3) ## Fixed - Fix host-metrics leaking zombie `[timeout]` processes in Alpine Linux containers. Before this release AppSignal collector relied on a proper init process that reaps child processes killed by system `timeout`. Now the collector terminates and reaps unresponsive child processes in host-metrics collection and a subreaper is no longer required. - Sanitize Redis spans' query text instead of the command name. The collector previously redacted `db.operation` / `db.operation.name`, which per the OpenTelemetry semantic conventions only contains the command verb (e.g. `GET`, `HMSET`) with nothing to redact, and left the full command-with-arguments in `db.query.text` / `db.statement` unredacted. The full command is now correctly sanitized, matching how the official OpenTelemetry Redis instrumentations emit data. As a side effect, Redis spans now group by command shape rather than by exact arguments, the same way SQL spans group by query shape. - Sanitize SQL queries for database systems reported using the current OpenTelemetry semantic conventions. The collector's SQL sanitization only recognized the `db.system` values from semantic conventions up to v1.29.0. Values renamed in v1.30.0, when the attribute became `db.system.name`, such as `microsoft.sql_server` for Microsoft SQL Server, were not recognized, so their queries were stored without sanitization. Both the older `db.system` values and the current `db.system.name` values are now recognized. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Pre-release: collector mode 2026-08-21 · Ruby · 5.0.0.rc.1 · [www.appsignal.com/changelog/ruby/2026-08-21-15-04-ruby-5.0.0.rc.1](https://www.appsignal.com/changelog/ruby/2026-08-21-15-04-ruby-5.0.0.rc.1) ## Added - Add a `collector_endpoint` configuration option (`APPSIGNAL_COLLECTOR_ENDPOINT` environment variable) that puts the integration in _collector mode_. In collector mode AppSignal reports traces, metrics and logs to an AppSignal Collector, over OTLP/HTTP. Collector mode requires Ruby 3.1 or newer, and the OpenTelemetry gems, which are not installed by default. Add the `appsignal-opentelemetry` gem alongside `appsignal` to install them. When they are missing or too old, AppSignal logs a warning and keeps reporting through its agent. - Add configuration options that map to OpenTelemetry resource attributes in collector mode: `service_name`, `filter_attributes`, `filter_function_parameters`, `filter_request_query_parameters`, `filter_request_payload`, `response_headers`, `send_function_parameters`, `send_request_query_parameters` and `send_request_payload`. In collector mode, existing options are passed to the collector as resource attributes as well: `name`, environment, `hostname`, `revision`, `ignore_actions`, `ignore_errors`, `ignore_namespaces`, `request_headers`, `filter_session_data` and `send_session_data`. Setting any of these without `collector_endpoint`, or setting `filter_parameters`, `filter_metadata` or `send_params` with it, logs a warning at startup. ## Added - Add the `appsignal-opentelemetry` gem. It installs the OpenTelemetry gems that AppSignal needs to run in collector mode. Add it alongside `appsignal` to opt into collector mode with a single gem instead of listing each OpenTelemetry gem yourself: ```ruby gem "appsignal" gem "appsignal-opentelemetry" ``` Collector mode requires Ruby 3.1 or newer, so this gem does too. Its version stays in lockstep with the `appsignal` gem. View the [Ruby gem v5.0.0.rc.1 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#500rc1) for more information. --- ## Honor custom CA file path during installation 2026-08-20 · Ruby · 4.10.1 · [www.appsignal.com/changelog/ruby/2026-08-20-14-47-ruby-4.10.1](https://www.appsignal.com/changelog/ruby/2026-08-20-14-47-ruby-4.10.1) ## Fixed - Use the CA certificate configured in `APPSIGNAL_CA_FILE_PATH` to download the AppSignal agent when installing this gem. The gem downloads the agent from our servers over HTTPS during installation. It always used the CA certificate bundled with the gem to verify that connection, whatever the value of the `ca_file_path` configuration option. This meant the installation failed behind a proxy that intercepts TLS connections, such as Zscaler, even when `APPSIGNAL_CA_FILE_PATH` pointed to a CA bundle that trusts the proxy. The bundled CA certificate is still used when `APPSIGNAL_CA_FILE_PATH` is not set. Thanks [@Cosmo](https://github.com/Cosmo) for your contribution! View the [Ruby gem v4.10.1 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4101) for more information. --- ## Fix Excon instrumentation and other improvements 2026-08-10 · Ruby · 4.10.0 · [www.appsignal.com/changelog/ruby/2026-08-10-11-08-ruby-4.10.0](https://www.appsignal.com/changelog/ruby/2026-08-10-11-08-ruby-4.10.0) ## Changed - Fix Excon requests being reported as taking almost no time. An Excon request is now recorded as a single `request.excon` event covering the whole request, so the event lasts as long as the request did. The `response.excon`, `retry.excon` and `error.excon` events no longer exist. AppSignal also no longer registers itself as Excon's instrumentor. - Report which template was rendered for collection and layout render events. - Name ROM query events after ROM, rather than after the database they ran against. A query made through ROM was reported as `query.postgres`, or `query.sqlite`, or whatever else the application's database was. Those queries are now all reported as `query.rom`. Events that dry-monitor reports and AppSignal has no formatter for are now named after their event id followed by `.dry`, so an event reported as `foo` becomes `foo.dry`. They had no group at all before. If you have a dashboard, trigger or saved filter that names one of these events, point it at the new name. ## Fixed - Fix a rare hang when stopping AppSignal in an application that sends check-ins. Stopping AppSignal waits for any check-in events that have not been transmitted yet, and it could wait forever instead of finishing. - Fix event formatters that register or unregister themselves. Calling `unregister` on the formatter itself, as in `MyFormatter.unregister("my.event")`, did nothing at all. The formatter stayed registered, and no error was raised and nothing was logged to say so. Calling `register` on the formatter itself stored it where AppSignal never looked for it, so it was never used to format an event. Registering and unregistering through `Appsignal::EventFormatter` itself, as in `Appsignal::EventFormatter.unregister("my.event", MyFormatter)`, was not affected and keeps working the same way. View the [Ruby gem v4.10.0 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#4100) for more information. --- ## Fix hosted collector uptime internal metric 2026-08-04 · Collector · 0.11.2 · [www.appsignal.com/changelog/collector/2026-08-04-08-42-collector-0.11.2](https://www.appsignal.com/changelog/collector/2026-08-04-08-42-collector-0.11.2) ## Fixed - Report the collector uptime internal metric in milliseconds. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## CLI v2.1.0 2026-08-03 · Tools (API, MCP, CLI) · 2.1.0 · [www.appsignal.com/changelog/tools/2026-08-03-11-04-cli-2.1.0](https://www.appsignal.com/changelog/tools/2026-08-03-11-04-cli-2.1.0) ## Added - Added `--notification-frequency` and `--notification-threshold` to `incidents update`, so incident notification behavior, including nth-occurrence notifications, can be configured from the CLI. - Trace listing commands now accept `--query`, allowing performance and error samples to be filtered by transaction tags such as `tag.region=eu-west` or by revision. - Added incident note listing, update, and delete commands, so you can find note IDs and edit or remove notes you authored. ## Changed - The bundled AppSignal skill now documents and recommends Markdown for structured incident notes, including findings, actions, code, and links. View the [CLI v2.1.0 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#210) for more information. --- ## Fix job corruption in Que 0.x 2026-07-27 · Ruby · 4.9.1 · [www.appsignal.com/changelog/ruby/2026-07-27-15-44-ruby-4.9.1](https://www.appsignal.com/changelog/ruby/2026-07-27-15-44-ruby-4.9.1) ## Fixed - Fix Que jobs being corrupted on enqueue when using Que 0.x. This was introduced in version 4.9.0. Que 1 and Que 2 were not affected. View the [Ruby gem v4.9.1 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#491) for more information. --- ## CLI v2.0.2 2026-07-20 · Tools (API, MCP, CLI) · 2.0.2 · [www.appsignal.com/changelog/tools/2026-07-20-14-25-cli-2.0.2](https://www.appsignal.com/changelog/tools/2026-07-20-14-25-cli-2.0.2) ## Added - Added appsignal-cli feedback so users and LLM workflows can send missing endpoint, feature, or broken behavior reports directly from the CLI, with optional contact email reuse for follow-up. ## Changed - Exception incident details now show error causes when sample data is available, making wrapped root causes visible directly from incidents show. View the [CLI v2.0.2 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#202) for more information. --- ## Report internal memory usage 2026-07-17 · Collector · 0.11.0 · [www.appsignal.com/changelog/collector/2026-07-17-12-06-collector-0.11.0](https://www.appsignal.com/changelog/collector/2026-07-17-12-06-collector-0.11.0) ## Added - Track Collector's memory usage as internal metrics. The Collector will now self-report memory usage and uptime every minute. ## Changed - Handle HTTP `HEAD` requests on the `/up` and `/` endpoints. These now respond with `200 OK` so health checks and uptime monitors that use `HEAD` requests no longer receive a `404` response. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Collector v0.11.1 2026-07-17 · Collector · 0.11.1 · [www.appsignal.com/changelog/collector/2026-07-17-15-59-collector-0.11.1](https://www.appsignal.com/changelog/collector/2026-07-17-15-59-collector-0.11.1) ## Changed - Log internal memory usage periodically. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Instrument job enqueues, Faraday, and other improvements 2026-07-16 · Ruby · 4.9.0 · [www.appsignal.com/changelog/ruby/2026-07-16-08-25-ruby-4.9.0](https://www.appsignal.com/changelog/ruby/2026-07-16-08-25-ruby-4.9.0) ## Added - Improve Faraday support. AppSignal now instruments Faraday requests automatically, without double-instrumenting the underlying HTTP client. Turn it off with the `instrument_faraday` option. Read more in our [Faraday integration docs](https://docs.appsignal.com/ruby/integrations/faraday). - Add config options to turn individual integrations off. Set `instrument_sidekiq`, `instrument_shoryuken`, `instrument_que`, `instrument_resque`, `instrument_delayed_job`, `instrument_active_job`, `instrument_excon` or `instrument_mongo` to `false` to disable that integration entirely. This turns off both the instrumentation of the jobs or requests and the enqueue instrumentation for that integration. They all default to `true`. Each can also be set through its environment variable, such as `APPSIGNAL_INSTRUMENT_SIDEKIQ`. - Instrument background job enqueues. Enqueuing a job now records an enqueue event on the active transaction, so enqueues made from within a web request or another job show up in the event timeline. This is recorded for Sidekiq (`enqueue.sidekiq`), Que (`enqueue.que`, plus `bulk_enqueue.que` for bulk enqueues on Que 2), Resque (`enqueue.resque`), Shoryuken (`enqueue.shoryuken`) and Delayed Job (`enqueue.delayed_job`). Each event is titled after the job being enqueued. For Active Job, the `enqueue.active_job` event is now recorded by AppSignal's own instrumentation rather than by Rails' native `enqueue.active_job` notification. The native notification is suppressed so the enqueue is recorded once, and the event is now titled after the job being enqueued. These enqueue events can be turned off with the `enable_job_enqueue_instrumentation` config option. Set it to `false` to stop recording enqueue events across all integrations, without affecting the instrumentation of the jobs themselves. It defaults to `true` and can also be set through the `APPSIGNAL_ENABLE_JOB_ENQUEUE_INSTRUMENTATION` environment variable. - Report the `grape` gem version in the environment metadata. For more information, see [our environment metadata docs](https://docs.appsignal.com/application/environment-metadata). ## Fixed - Instrument HTTP.rb chained requests on http 6. Requests made through a chained client -- `HTTP.follow.get(...)`, `HTTP.headers(...).get(...)`, and so on -- go through `HTTP::Session` rather than `HTTP::Client`, and were not being recorded. They now produce a `request.http_rb` event like any other request. View the [Ruby gem v4.9.0 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#490) for more information. --- ## Support HTTPoison 3.0 2026-07-09 · Elixir · 2.17.4 · [www.appsignal.com/changelog/elixir/2026-07-09-14-46-elixir-2.17.4](https://www.appsignal.com/changelog/elixir/2026-07-09-14-46-elixir-2.17.4) ## Changed - Allow HTTPoison 3.0 to be used as an optional dependency. Applications on HTTPoison 3.0 can now use AppSignal's HTTPoison instrumentation without a version conflict. View the [Elixir package v2.17.4 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2174) for more information. --- ## Export sample details in Markdown for your AI assistant 2026-07-06 · App · [www.appsignal.com/changelog/app/2026-07-06-download-sample-markdown](https://www.appsignal.com/changelog/app/2026-07-06-download-sample-markdown) Exception and performance sample detail pages now export as Markdown, alongside the existing JSON download. Open the sample's actions menu and select **Download Markdown**, or use the copy icon to copy it to your clipboard. The Markdown is document in sections covering the backtrace, timeline, parameters, attributes, environment, deploy marker, and a context block. Paste it into an AI assistant like Claude or Codex to ask questions about the sample. The **Download JSON** row now has the same copy icon, so you can copy either format the same way. --- ## Improve version and config visibility 2026-07-03 · Collector · 0.10.1 · [www.appsignal.com/changelog/collector/2026-07-03-11-43-collector-0.10.1](https://www.appsignal.com/changelog/collector/2026-07-03-11-43-collector-0.10.1) ## Changed - Improve collector status visibility. The collector now repeats its version and configuration details while it is running, making it easier to confirm which setup is active when reviewing logs. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Collector v0.10.0 2026-07-02 · Collector · 0.10.0 · [www.appsignal.com/changelog/collector/2026-07-02-12-35-collector-0.10.0](https://www.appsignal.com/changelog/collector/2026-07-02-12-35-collector-0.10.0) ## Changed - Improve the sampling strategy used for error and performance issue tracking. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## CLI v2.0.1 2026-07-01 · Tools (API, MCP, CLI) · 2.0.1 · [www.appsignal.com/changelog/tools/2026-07-01-09-46-cli-2.0.1](https://www.appsignal.com/changelog/tools/2026-07-01-09-46-cli-2.0.1) ## Added - Added `traces` commands, also available as `samples`, for listing performance samples/traces and error traces, then inspecting their span trees through the AppSignal REST tracing API. Traces can also be fetched and inspected directly from performance and exception incident numbers, and `--page-all` can fetch beyond the first page of trace results. ## Changed - Incident list commands now render with the same table formatting as other list commands, making human-readable output easier to scan. View the [CLI v2.0.1 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#201) for more information. --- ## Fixes for host metrics and collector mode 2026-06-23 · Python · 1.6.5 · [www.appsignal.com/changelog/python/2026-06-23-python-1.6.5](https://www.appsignal.com/changelog/python/2026-06-23-python-1.6.5) ## Changed - Bundled certificates have been updated. - Use system-specific operation name in messaging span names. When `messaging.operation.name` is present (e.g. `Queue.add`), it is used directly as the span name prefix: `Queue.add (myQueue)`. When only the generic `messaging.operation.type` is available (e.g. `send`), the word "message" is added for clarity: `send message (myQueue)`. ## Fixed - Continue reporting non-disk host metrics when a mount is frozen. - Emit the `appsignal.action_name` attribute instead of `appsignal.root_name` when `set_root_name` is used in collector mode. The collector only reads the action name from `appsignal.action_name`, so root names set this way were previously ignored, falling back to the OpenTelemetry span name. - Update the OpenTelemetry span name directly when `set_name` is used in collector mode, instead of setting the `appsignal.name` attribute. The collector uses the span name as-is, so names set this way were previously ignored. - Emit the `db.system.name` and `db.query.text` semantic-convention attributes instead of `appsignal.sql_body` when `set_sql_body` is used in collector mode. This fixes SQL query sanitization when using the experimental collector mode. - Fix host-metrics leaking zombie `[timeout]` processes in Alpine linux containers. Before this release AppSignal agent relied on a proper init process that reaps child processes killed by system `timeout`. Now the agent terminates and reaps unresponsive child processes in host-metrics collection and a subreaper is no longer required. - Emit request parameters and headers using the attribute names the collector recognizes when in collector mode. `set_params` now emits `appsignal.request.payload` instead of `appsignal.request.parameters`, and `set_header` uses the `http.request.header` prefix instead of `appsignal.request.headers`. The collector and server do not recognize the previous names, so this sample data was previously dropped in collector mode. View the [Python package v1.6.5 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#165) for more information. --- ## Host metrics collection zombie process fix 2026-06-23 · Ruby · 4.8.6 · [www.appsignal.com/changelog/ruby/2026-06-23-ruby-4.8.6](https://www.appsignal.com/changelog/ruby/2026-06-23-ruby-4.8.6) ## Fixed - Fix host-metrics leaking zombie `[timeout]` processes in Alpine linux containers. Before this release AppSignal agent relied on a proper init process that reaps child processes killed by system `timeout`. Now the agent terminates and reaps unresponsive child processes in host-metrics collection and a subreaper is no longer required. View the [Ruby gem v4.8.6 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#486) for more information. --- ## Public AppSignal CLI release! 2026-06-18 · Tools (API, MCP, CLI) · 2.0.0 · [www.appsignal.com/changelog/tools/2026-06-18-cli-2.0.0](https://www.appsignal.com/changelog/tools/2026-06-18-cli-2.0.0) Our new AppSignal CLI brings your monitoring data into the terminal. Tail logs, triage incidents, manage dashboards and anomaly detection triggers, and turn logs into metrics, all without leaving the shell where you run your tests and deploys. It's built for people and AI agents. Every command returns human-readable output or JSON (`--output json`), so the same tool you reach for during an incident can also feed structured data to a coding agent. The CLI also bundles an agent skill for Claude, Codex, and OpenCode. Sign in with OAuth and you're ready to go: ```sh appsignal-cli auth login ``` {/* TODO: placeholder link — replace with the dedicated AppSignal CLI docs URL when available */} Install it with Homebrew (`brew install appsignal/appsignal-cli/appsignal-cli`) or the install script, then read the [documentation](https://docs.appsignal.com/cli) to get started. ## Changed - `apps list` now uses the current OAuth account to determine the organization automatically and saves that org to the active config. You no longer need to pass `--org` when listing apps for the signed-in account. - `incidents update` now accepts multiple incident numbers for bulk state changes, so you can close or reopen an explicit set of incidents in one command. It also adds `--assign-me` to assign the incident to the authenticated CLI user without needing to look up your user ID first. - OAuth login now requests the `user:read` scope needed for browser-based AppSignal account access, and older tokens now produce a clearer re-authentication message when that scope is missing. The unsupported `apps orgs` command has been removed. - Added dashboard management commands to list, create, and update AppSignal dashboards from the CLI. - `appsignal-cli` now sends a minimal best-effort telemetry event for each command run to help measure CLI usage and reliability. The event includes only the command path, success or failure, duration, CLI version, and output format, and you can disable it entirely with `APPSIGNAL_CLI_TELEMETRY=0`. - OAuth is now the default auth login flow, so running `appsignal-cli auth login` opens the browser-based sign-in flow without requiring `--oauth`. Personal token login remains available by passing `--token` explicitly. ## Removed - OAuth is now the default authentication method. `appsignal-cli auth login` opens the browser flow directly, while personal API token login remains available with `--token`. View the [CLI v2.0.0 changelog](https://github.com/appsignal/appsignal-cli/blob/main/CHANGELOG.md#200) for more information. --- ## Fix host metrics timeout and other improvements 2026-06-10 · Node.js · 3.8.1 · [www.appsignal.com/changelog/nodejs/2026-06-10-node.js-3.8.1](https://www.appsignal.com/changelog/nodejs/2026-06-10-node.js-3.8.1) ## Fixed - Continue reporting non-disk host metrics when a mount is frozen. - Fix host-metrics leaking zombie `[timeout]` processes in Alpine linux containers. Before this release AppSignal agent relied on a proper init process that reaps child processes killed by system `timeout`. Now the agent terminates and reaps unresponsive child processes in host-metrics collection and a subreaper is no longer required. - Ensure `sendError` ends its span even when the callback throws. View the [Node.js package v3.8.1 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#381) for more information. --- ## Improve stability 2026-06-09 · Collector · 0.9.7 · [www.appsignal.com/changelog/collector/2026-06-09-collector-0.9.7](https://www.appsignal.com/changelog/collector/2026-06-09-collector-0.9.7) ## Added - Allow `appsignal.group` and `appsignal.format` attributes in OpenTelemetry logs to override the log line's group and format. When present, `appsignal.group` overrides the resource-level service name as the log group, and `appsignal.format` (one of `plaintext`, `logfmt`, `json`, `autodetect`) overrides the log source's parsing format. ## Fixed - Fix crashes when truncating attribute keys and values whose length limit fell in the middle of a multi-byte UTF-8 character. Truncation now rounds the cut point down to the nearest character boundary instead of panicking. - Continue reporting non-disk host metrics when a mount is frozen. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Prevent host-metrics leaking zombie `[timeout]` processes 2026-06-04 · Elixir · 2.17.3 · [www.appsignal.com/changelog/elixir/2026-06-04-elixir-2.17.3](https://www.appsignal.com/changelog/elixir/2026-06-04-elixir-2.17.3) ## Fixed - Fix host-metrics leaking zombie `[timeout]` processes in Alpine linux containers. Before this release AppSignal agent relied on a proper init process that reaps child processes killed by system `timeout`. Now the agent terminates and reaps unresponsive child processes in host-metrics collection and a subreaper is no longer required. View the [Elixir package v2.17.3 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2173) for more information. --- ## Filter internal Sidekiq data, and fix bugs 2026-06-02 · Ruby · 4.8.5 · [www.appsignal.com/changelog/ruby/2026-06-02-ruby-4.8.5](https://www.appsignal.com/changelog/ruby/2026-06-02-ruby-4.8.5) ## Changed - Exclude more Sidekiq internal job attributes (`cattr`, `tags`, `retry_for` and `unique_for`) from the tags reported for Sidekiq jobs. ## Fixed - Continue reporting non-disk host metrics when a mount is frozen. - Prevent a `NoMethodError` in the Active Job, Rake, Sidekiq, Delayed Job, and WebMachine instrumentations when the creation of an AppSignal transaction is interrupted by process shutdown signals. View the [Ruby gem v4.8.5 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#485) for more information. --- ## Emit Ecto query metrics 2026-05-26 · Elixir · 2.17.2 · [www.appsignal.com/changelog/elixir/2026-05-26-elixir-2.17.2](https://www.appsignal.com/changelog/elixir/2026-05-26-elixir-2.17.2) ## Added - Emit distribution metrics from the Ecto integration. Each Ecto query telemetry event now also reports its timing values as `ecto_query_time`, `ecto_queue_time`, `ecto_decode_time`, `ecto_idle_time` and `ecto_total_time` distribution metrics. All five metrics are tagged by `repo` and `hostname`. The `ecto_query_time`, `ecto_decode_time` and `ecto_total_time` metrics are additionally tagged by `repo` and `source` (the Ecto table). This surfaces pool waits, decode time, idle connection time and per-table latency as standalone metrics in addition to the existing query span. ## Fixed - Preserve sub-millisecond precision when reporting timing distribution metrics. The Ecto (`ecto_query_time`, `ecto_queue_time`, `ecto_decode_time`, `ecto_idle_time`, `ecto_total_time`) and Oban (`oban_job_duration`, `oban_job_queue_time`) distribution metrics now report fractional milliseconds, instead of being truncated to whole milliseconds. Sub-millisecond measurements were previously rounded down to zero. View the [Elixir package v2.17.2 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2172) for more information. --- ## Support Render's metrics stream 2026-05-18 · Collector · 0.9.6 · [www.appsignal.com/changelog/collector/2026-05-18-collector-0.9.6](https://www.appsignal.com/changelog/collector/2026-05-18-collector-0.9.6) ## Added - Support Render's OpenTelemetry metrics stream by converting its host-related metrics into AppSignal host metrics. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Elixir package v2.17.1 2026-05-14 · Elixir · 2.17.1 · Security · [www.appsignal.com/changelog/elixir/2026-05-14-elixir-2.17.1](https://www.appsignal.com/changelog/elixir/2026-05-14-elixir-2.17.1) ## Fixed - Continue reporting non-disk host metrics when a mount is frozen. - Fix compatibility with Finch 0.22+. This change moves SSL and proxy options to pool-level `conn_opts` in `Finch.start_link`. ## Security - [CVE-2026-32686](https://cna.erlef.org/cves/CVE-2026-32686.html) describes an unauthenticated remote Denial of Service vulnerability in `decimal` before `3.0.0`. Loosen `decimal` requirement to allow `~> 3.0` and fix compatibility with `ecto`. View the [Elixir package v2.17.1 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2171) for more information. --- ## Log-based metrics, now in beta 2026-05-13 · App · Beta · [www.appsignal.com/changelog/app/2026-05-13-log-based-metrics](https://www.appsignal.com/changelog/app/2026-05-13-log-based-metrics) Turn any log source into a stream of metrics — without writing application code or paying to index every line. Log-based metrics is now in beta, and joins the existing beta and preview features in [AppSignal Labs](https://docs.appsignal.com/labs). Define a query against any log source, choose a metric type, and AppSignal extracts the value during ingestion. ![Log-based metrics: log lines flowing into metric charts on a dashboard](/assets/changelog/2026-05/log-based-metrics.png) AppSignal supports three metric types: - **Count** — count matching log lines (5xx responses, failed logins, retries). - **Gauge** — record the value of an attribute at ingestion (queue depth, connection count). - **Measurement** — build a histogram of a numeric attribute over time (request duration, payload size, job runtime). Extraction runs as a log line action, in an order you control. Place it before any filter actions on the same source and you can keep the metric while discarding the underlying log line — handy for high-volume sources you don't need to search line-by-line. To create one, open the **Logs Explorer** and select **Create a metric** — either from the view's ⋮ menu (using the current query) or from a numeric attribute on any log line (using that attribute as the field). Manage your metrics on the new **Metrics** page under Logging. Any metrics created through the [AppSignal MCP](https://docs.appsignal.com/mcp-server) `manage_log_line_action` tool are visible there too. Read the [documentation](https://docs.appsignal.com/logging/metrics.html) for examples and patterns. --- ## Dark mode is now in beta 2026-05-06 · App · Beta · [www.appsignal.com/changelog/app/2026-05-06-dark-mode](https://www.appsignal.com/changelog/app/2026-05-06-dark-mode) A dark theme for the AppSignal UI is now available as part of [AppSignal Labs](https://docs.appsignal.com/labs). Light mode remains the default. To opt in, click your profile picture in the top-right corner and switch the **Theme** toggle to: - **Light** — the default - **Dark** — always-on dark mode - **System** — follows your OS preference We're rolling this out gradually as we polish the rough edges, so expect a few screens that aren't quite there yet. Found one that doesn't look right? Tell us — that's the whole point of Labs. [Learn more about AppSignal Labs →](https://docs.appsignal.com/labs) --- ## Limit collector memory usage 2026-04-24 · Collector · 0.9.5 · [www.appsignal.com/changelog/collector/2026-04-24-collector-0.9.5](https://www.appsignal.com/changelog/collector/2026-04-24-collector-0.9.5) ## Fixed - Cap the amount of metric states stored for cumulative-to-delta conversion, preventing high-cardinality tag combinations from causing excessive memory usage. - Evict and block traces that accumulate large amounts of orphaned spans, preventing them from growing unboundedly in memory. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## AppSignal JavaScript `urql` package v1.0.0 2026-04-21 · JavaScript · @appsignal/urql@1.0.0 · [www.appsignal.com/changelog/javascript/2026-04-21-javascript--appsignal-urql-1.0.0](https://www.appsignal.com/changelog/javascript/2026-04-21-javascript--appsignal-urql-1.0.0) ## Added - Our new `@appsignal/urql` package allows reporting all GraphQL errors automatically through a custom `urql` exchange: ```javascript import { createClient, fetchExchange } from "urql"; import Appsignal from "@appsignal/javascript"; import { createAppsignalExchange } from "@appsignal/urql"; const appsignal = new Appsignal({ key: "YOUR FRONTEND API KEY", }); const client = createClient({ url: "https://api.example.com/graphql", exchanges: [createAppsignalExchange(appsignal), fetchExchange], }); ``` View the [AppSignal JavaScript urql v1.0.0 changelog](https://github.com/appsignal/appsignal-javascript/blob/main/packages/urql/CHANGELOG.md#100) for more information. --- ## MCP Server: Performance, Logs, and More 2026-04-15 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-04-15-mcp-performance-logs-oauth](https://www.appsignal.com/changelog/tools/2026-04-15-mcp-performance-logs-oauth) AppSignal MCP graduates from beta to preview with this release. The AppSignal MCP server now exposes 24 tools across seven areas — up from 18 — with two new capability areas and expanded write access throughout. **What's new:** - **Performance:** Ask your agent which actions are slowest, pull traces for a specific action, inspect full span trees, and drill into individual spans. Works with both sample-based performance data and OpenTelemetry traces. - **Logging:** Search log lines using AppSignal's expression syntax, and set up log processing rules directly from your editor: create filters, trigger alerts, extract metrics from log lines, and control execution order. - **Anomaly triggers:** In addition to listing triggers and alerts, you can now create, update, and archive anomaly detection triggers without leaving your editor. - **OAuth support:** The MCP server now supports OAuth authentication, which unlocks GitHub Copilot CLI support. Token permissions now include the `performance` and `logging` toolsets alongside `app`, `exceptions`, `metrics`, `anomalies`, and `dashboards`. For setup instructions and the full tool reference, see the [MCP documentation](https://docs.appsignal.com/mcp-server). Read the [full blog post](https://blog.appsignal.com/2026/04/15/appsignal-mcp-server-performance-logs-and-more) for the complete breakdown. --- ## Fix compatibility with http.rb v6 2026-03-20 · Ruby · 4.8.4 · [www.appsignal.com/changelog/ruby/2026-03-20-ruby-4.8.4](https://www.appsignal.com/changelog/ruby/2026-03-20-ruby-4.8.4) ## Changed - Bundled certificates have been updated. ## Fixed - Fix compatibility with `http` (http.rb) gem version 6.0.0 and higher. View the [Ruby gem v4.8.4 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#484) for more information. --- ## Fix exit with parent on macOS 2026-03-20 · Wrap · 0.3.2 · [www.appsignal.com/changelog/wrap/2026-03-20-wrap-0.3.2](https://www.appsignal.com/changelog/wrap/2026-03-20-wrap-0.3.2) ## Fixed - Fix an issue where the child process was not terminated on macOS when the parent process was killed by an uncatchable signal, such as `SIGSTOP` or `SIGKILL`. View the [appsignal-wrap v0.3.2 changelog](https://github.com/appsignal/appsignal-wrap/blob/main/CHANGELOG.md#032) for more information. --- ## Update OpenTelemetry dependencies to v2 2026-03-17 · Node.js · 3.8.0 · [www.appsignal.com/changelog/nodejs/2026-03-17-node.js-3.8.0](https://www.appsignal.com/changelog/nodejs/2026-03-17-node.js-3.8.0) ## Changed - Update OpenTelemetry dependencies to v2. All bundled OpenTelemetry packages have been updated to their OpenTelemetry v2-compatible versions. This resolves compatibility issues when third-party span processors or instrumentations are used alongside AppSignal, which could cause spans to silently drop due to v1/v2 incompatibilities. The `@opentelemetry/instrumentation-redis-4` package has been removed. Redis v4 instrumentation is now handled by `@opentelemetry/instrumentation-redis`, which supports both Redis v3 and v4. - Update Prisma instrumentation to v7. The `@prisma/instrumentation` package has been updated from v6 to v7. The `middleware` config option has been removed, as Prisma dropped its middleware API in Prisma v5. Prisma's native tracing is now the only supported instrumentation method. - Bundled certificates have been updated. - Update BullMQ OpenTelemetry extractor to support new messaging semantic conventions. - Use system-specific operation name in messaging span names. View the [Node.js package v3.8.0 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#380) for more information. --- ## Open backtrace lines in your local editor 2026-03-16 · App · [www.appsignal.com/changelog/app/2026-03-16-backtrace-editor-links](https://www.appsignal.com/changelog/app/2026-03-16-backtrace-editor-links) Once configured, open any app code line from an exception backtrace directly in your local editor. ![Backtrace lines with Open in editor button](/assets/changelog/2026-03/open-in-editor.png) Before setup, the option is available in the extras menu, accessible via the there dots icon. ![Backtrace line menu with Open in editor option](/assets/changelog/2026-03/open-in-editor-setup.png) Set your preferred editor once per app under **App Settings → Editor preferences**. Each developer on your team can configure their own editor independently. Supported editors: **VS Code**, **Cursor**, **Windsurf**, **Zed**, **RubyMine**, and **Sublime Text**. ![Editor preferences settings](/assets/changelog/2026-03/settings.png) --- ## Public MCP Endpoint 2026-03-12 · Tools (API, MCP, CLI) · [www.appsignal.com/changelog/tools/2026-03-12-mcp-public-endpoint](https://www.appsignal.com/changelog/tools/2026-03-12-mcp-public-endpoint) Connect AI agents to your AppSignal monitoring data — no Docker container required. Our MCP server is now available as a hosted endpoint at `https://appsignal.com/api/mcp`. To generate a token, select your profile, go to **Account Settings > MCP Tokens**. Point your agent at the endpoint, and you're ready to go. Once connected, your AI agent gets access to 18 tools across five areas: - **Error incidents** — list, search, and bulk-update exceptions; assign team members and add investigation notes. - **Anomaly detection** — browse open alerts and review trigger configurations for any metric. - **Metrics** — discover available metrics, query timeseries data, and get aggregated values with tag filtering. - **Dashboards** — create dashboards and add or update chart visuals from your editor. - **App discovery** — find apps, environments, namespaces, users, and notifiers. Works with Claude, Cursor, Windsurf, Zed, VS Code, and any agent that supports the MCP protocol. For setup instructions, see the [MCP documentation](https://docs.appsignal.com/mcp-server). Read the [full blog post](https://blog.appsignal.com/2026/03/18/appsignal-mcp-server-connect-ai-agents-to-your-monitoring-data.html) for more details. --- ## HTTPoison instrumentation 2026-03-09 · Elixir · 2.17.0 · [www.appsignal.com/changelog/elixir/2026-03-09-elixir-2.17.0](https://www.appsignal.com/changelog/elixir/2026-03-09-elixir-2.17.0) ## Added - Add HTTPoison instrumentation. HTTP requests made with HTTPoison will appear as `request.httpoison` events on your performance samples' event timeline. HTTPoison does not emit telemetry events, so the instrumentation is opt-in. Use `Appsignal.HTTPoison` in place of `HTTPoison` when making requests, or replace `use HTTPoison.Base` with `use Appsignal.HTTPoison.Base` for custom client modules. Response types (`%HTTPoison.Response{}`, `%HTTPoison.Error{}`, etc.) are unchanged. ## Changed - Bundled certificates have been updated. View the [Elixir package v2.17.0 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2170) for more information. --- ## Fix trace grouping and ignore noisy traces 2026-02-25 · Collector · 0.9.4 · [www.appsignal.com/changelog/collector/2026-02-25-collector-0.9.4](https://www.appsignal.com/changelog/collector/2026-02-25-collector-0.9.4) ## Fixed - Fix an issue where certain noisy traces would not be ignored on Next.js and Flask. - Fix an issue where traces representing requests performed from different HTTP ports on the client's end would be grouped as different traces. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## More Layout Controls for Dashboards 2026-02-23 · App · [www.appsignal.com/changelog/app/2026-02-23-dashboard-layout](https://www.appsignal.com/changelog/app/2026-02-23-dashboard-layout) Your dashboards now bend to your workflow — not the other way around. - **Drag-and-drop widgets** Reposition any widget by clicking and dragging it wherever makes sense. No grid constraints, no fixed columns — place widgets freely and build a layout that matches how you actually think about your data. - **Resizable widgets** Expand a chart that deserves more real estate. Shrink the ones that don't. Drag any widget edge to resize it and mix compact summaries with detailed graphs in the same view. Click **Edit dashboard** to start reshaping your layout. --- ## Amazon CloudWatch metrics via Amazon Data Firehose 2026-02-18 · App · [www.appsignal.com/changelog/app/2026-02-18-cloudwatch-metrics](https://www.appsignal.com/changelog/app/2026-02-18-cloudwatch-metrics) You can now store Amazon CloudWatch metrics in AppSignal through Amazon Data Firehose. Monitor your most critical AWS services directly from your AppSignal dashboards: - **RDS** — track database connections, read/write latency and CPU utilization - **S3** — monitor bucket size, request counts and error rates - **EC2** — observe instance CPU, network traffic and disk I/O - **Lambda** — keep an eye on invocations, duration and throttles - **SQS** — watch queue depth, message age and processing rates - And more! When CloudWatch metrics are detected, we automatically create dashboards for your AWS services. Setup only takes two steps: create a Firehose stream pointed at AppSignal and connect it to a CloudWatch metric stream. See our [CloudWatch metrics documentation](https://docs.appsignal.com/metrics/cloudwatch.html) to get started. --- ## Fix error reporting in collector mode 2026-02-18 · Python · 1.6.4 · [www.appsignal.com/changelog/python/2026-02-18-python-1.6.4](https://www.appsignal.com/changelog/python/2026-02-18-python-1.6.4) ## Fixed - Fix an issue where errors set with the `set_error` helper would not always be reported as errors in AppSignal when using collector mode. View the [Python package v1.6.4 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#164) for more information. --- ## Add `default_tags` configuration option 2026-02-17 · Ruby · 4.8.3 · [www.appsignal.com/changelog/ruby/2026-02-17-ruby-4.8.3](https://www.appsignal.com/changelog/ruby/2026-02-17-ruby-4.8.3) ## Added - Add a `default_tags` configuration option. Tags set in this configuration option will be set for all transactions. View the [Ruby gem v4.8.3 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#483) for more information. --- ## Fix HTTP route events and heartbeat shutdown 2026-02-11 · Python · 1.6.2 · [www.appsignal.com/changelog/python/2026-02-11-python-1.6.2](https://www.appsignal.com/changelog/python/2026-02-11-python-1.6.2) ## Fixed - Fix 'unknown' events being reported for some HTTP routes. - Fix an issue where usage of continuous heartbeats would stop an application from winding down unless `appsignal.stop()` was called. View the [Python package v1.6.2 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#162) for more information. --- ## Fix check-ins blocking application shutdown 2026-02-11 · Python · 1.6.3 · [www.appsignal.com/changelog/python/2026-02-11-python-1.6.3](https://www.appsignal.com/changelog/python/2026-02-11-python-1.6.3) ## Fixed - Fix an issue where using check-ins blocks the application from shutting down. View the [Python package v1.6.3 changelog](https://github.com/appsignal/appsignal-python/blob/main/CHANGELOG.md#163) for more information. --- ## Better Database and HTTP span recognition 2026-02-09 · Collector · 0.9.3 · [www.appsignal.com/changelog/collector/2026-02-09-collector-0.9.3](https://www.appsignal.com/changelog/collector/2026-02-09-collector-0.9.3) ## Added - Use `db.stored_operation.name` as one of the attributes to determine if two spans are the same. When it is present, ignore `db.statement` and `db.query.text` for the same purpose. ## Changed - Improve recognition of HTTP client spans. This will help our 'slow requests' feature recognize grouped HTTP client spans and improve our N+1 detection. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Require parent spans for database and HTTP 2026-02-05 · Node.js · 3.7.4 · [www.appsignal.com/changelog/nodejs/2026-02-05-node.js-3.7.4](https://www.appsignal.com/changelog/nodejs/2026-02-05-node.js-3.7.4) ## Changed - Require parent spans on database and outgoing HTTP instrumentations that support it. When a database query is performed using the `ioredis`, `pg`, `redis` or `mongoose` libraries, or when an outgoing HTTP request is performed using the `http` module, a span will only be created if a trace has already been started in the current active context, that is, if the span to be created would have a parent. This helps prevent database queries and outgoing HTTP requests happening in uninstrumented contexts from counting towards your requests quota. ## Fixed - Add support for Koa v3. View the [Node.js package v3.7.4 changelog](https://github.com/appsignal/appsignal-nodejs/blob/main/CHANGELOG.md#374) for more information. --- ## Fix install on Ruby 4 and log configure 2026-02-05 · Ruby · 4.8.2 · [www.appsignal.com/changelog/ruby/2026-02-05-ruby-4.8.2](https://www.appsignal.com/changelog/ruby/2026-02-05-ruby-4.8.2) ## Added - Log where `Appsignal.configure` is called. When a warning is emitted about `Appsignal.configure` being called from an application where `config/appsignal.yml` or `config/appsignal.rb` exist, log the location from which `Appsignal.configure` was called alongside the location of the configuration file. ## Fixed - Fix the `bundle exec appsignal install` CLI command on Ruby 4 by removing the dependency on the `ostruct` gem, which is no longer part of the standard library. View the [Ruby gem v4.8.2 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#482) for more information. --- ## Updated Log Query Syntax and Customizable Views 2026-01-28 · App · [www.appsignal.com/changelog/app/2026-01-28-log-query-syntax](https://www.appsignal.com/changelog/app/2026-01-28-log-query-syntax) In the Logging `Live` and `Explore` views, we have improved the query syntax with support for nested attributes, and simplified attribute definition in queries. Existing saved views and triggers will need to be migrated to the new syntax, contact support@appsignal.com for assistance. Read more in our [Query Syntax documentation](https://docs.appsignal.com/logging/query-syntax.html). ## Log Views are now customizable Log attributes can be added as additional columns and saved in views. Click `Edit table` from the options dropdown to add more columns. Click `Save view` to persist your customized log view. ![New: Query Log Syntax](/assets/changelog/2026-01/query-log-syntax.png) --- ## Heroku Fir support 2026-01-06 · App · [www.appsignal.com/changelog/app/2026-01-06-heroku-fir](https://www.appsignal.com/changelog/app/2026-01-06-heroku-fir) We've added Heroku Fir support. By pointing Heroku Fir's telemetry drain to our collector we report the following: - Host metrics: CPU usage, memory usage and free memory. - Metrics from add-ons, such as PostgreSQL and Redis. These will be visible in automatically added dashboards. - Logs from the Heroku router and API. For more information, see the Heroku Fir sections in our [Heroku documentation](https://docs.appsignal.com/heroku/setup.html). --- ## OpenTelemetry performance alerting 2026-01-06 · App · [www.appsignal.com/changelog/app/2026-01-06-trace-performance-alerting](https://www.appsignal.com/changelog/app/2026-01-06-trace-performance-alerting) AppSignal supports OpenTelemetry trace data. It's now possible to set up performance alerting for traces. In a trace summary view, click the "Add new" link in the "Triggers" box. ![Trace summary page with the triggers box highlighted](/assets/changelog/2026-01/trace-trigger-new.png) In the opened "New trigger" modal, configure the alerting, select your preferred notifier, and save the trigger. It is possible to configure alerting on the mean response time of requests, and the 90th and 90th percentile of the response time. Use a warm-up to only be alerted if this continues for as long as the warm-up is configured. ![New trigger modal with the slow actions form highlighted](/assets/changelog/2026-01/trace-trigger-form.png) Now, AppSignal will alert you about new slow actions. ![New trigger modal with the slow actions form highlighted](/assets/changelog/2026-01/trace-trigger-box.png) _Note: This only works for our [OpenTelemetry tracing feature](https://docs.appsignal.com/opentelemetry)._ --- ## Vercel drains: Speed insights and traces 2026-01-06 · App · [www.appsignal.com/changelog/app/2026-01-06-vercel-drains](https://www.appsignal.com/changelog/app/2026-01-06-vercel-drains) AppSignal supports more Vercel drains: Speed Insights and OpenTelemetry traces. ## Speed Insights Vercel Drains provide support for [Web Vitals](https://web.dev/articles/vitals) through the Speed Insights drain, like First Contentful Paint and Largest Contentful Paint. These metrics can serve as signals for delivering great user experience on the web. When Speed Insights metrics are detected, we will automatically create a "Web Vitals" dashboard for your application. ## Traces Report traces from Vercel's infrastructure to get more insights into how all parts of your application are performing. This works with our OpenTelemetry tracing feature and will report errors and performance data from your application and Vercel infrastructure (Vercel functions and edge network). --- For more information, see these documentation pages: - [Vercel Speed Insights](https://docs.appsignal.com/vercel/speed-insights.html) - [Traces from Vercel applications](https://docs.appsignal.com/vercel/traces.html) --- ## New chart type: Number chart 2025-12-18 · App · [www.appsignal.com/changelog/app/2025-12-18-number-chart](https://www.appsignal.com/changelog/app/2025-12-18-number-chart) Added a new chart type for dashboards: the number chart. The number chart displays a number on the dashboard instead of a line graph. Useful when a single value gives enough information at a glance. The chart supports multiple ways of calculating the metric data for the timeframe selected, such as: - Maximum value: Show the highest metric value. - Minimum value: Show the lowest metric value. - Average value: Show the average of the metric values. - Total value: Show the combined value of the metric values. - First value: Show the first metric value. - Last value: Show the last metric value. To add a number chart, go to [your application](https://appsignal.com/redirect-to/app?to=dashboard) in AppSignal, create or open a dashboard, click "Add chart", and select "Number" in the sidebar. ![Screenshot AppSignal UI showing a number chart](/assets/changelog/2025-12/number-chart.png) --- ## Allow app-level push API keys 2025-12-16 · Collector · 0.9.2 · [www.appsignal.com/changelog/collector/2025-12-16-collector-0.9.2](https://www.appsignal.com/changelog/collector/2025-12-16-collector-0.9.2) ## Changed - Allow the use of app-level push API keys. When an app-level push API key is used, the resource attributes for the name and environment should not be specified. These resource attributes are now optional, although the use of one requires the other. - Make most resource attributes optional. Allow for the resource attributes pertaining the revision, the hostname, the language integration and the application path to not be present. This allows the AppSignal collector to more easily ingest data from arbitrary OpenTelemetry sources. Note that usage of these resource attributes is still recommended. Traces sent without these attributes may be tagged with the wrong hostname or revision, or have their error backtraces parsed incorrectly. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Disable `ActiveSupport::EventReporter` logs 2025-12-16 · Ruby · 4.8.1 · [www.appsignal.com/changelog/ruby/2025-12-16-ruby-4.8.1](https://www.appsignal.com/changelog/ruby/2025-12-16-ruby-4.8.1) ## Changed - Disable the `enable_active_support_event_log_reporter` configuration option by default. View the [Ruby gem v4.8.1 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#481) for more information. --- ## Ruby gem v4.8.0 2025-12-04 · Ruby · 4.8.0 · [www.appsignal.com/changelog/ruby/2025-12-04-ruby-4.8.0](https://www.appsignal.com/changelog/ruby/2025-12-04-ruby-4.8.0) ## Added - Report events from Rails 8.1's Structured Event Reporting (`ActiveSupport::EventReporter`) as logs. ## Fixed - Fix ActiveSupport::Notifications event instrumentation on Rails 8.1 when no listeners are registered. View the [Ruby gem v4.8.0 changelog](https://github.com/appsignal/appsignal-ruby/blob/main/CHANGELOG.md#480) for more information. --- ## Limit required headers for Heroku Telemetry drain 2025-12-02 · Collector · 0.9.1 · [www.appsignal.com/changelog/collector/2025-12-02-collector-0.9.1](https://www.appsignal.com/changelog/collector/2025-12-02-collector-0.9.1) ## Changed - Use `heroku.release.version` resource attribute as a fallback value for `revision` for Heroku Fir applications. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Elixir package v2.16.0 2025-12-01 · Elixir · 2.16.0 · [www.appsignal.com/changelog/elixir/2025-12-01-elixir-2.16.0](https://www.appsignal.com/changelog/elixir/2025-12-01-elixir-2.16.0) ## Changed - Disable the error backend by default With new ways of instrumenting errors added, the error backend is unneeded in most setups. Disable it by default to make it opt-in. View the [Elixir package v2.16.0 changelog](https://github.com/appsignal/appsignal-elixir/blob/main/CHANGELOG.md#2160) for more information. --- ## Collector v0.9.0 2025-11-24 · Collector · 0.9.0 · [www.appsignal.com/changelog/collector/2025-11-24-collector-0.9.0](https://www.appsignal.com/changelog/collector/2025-11-24-collector-0.9.0) ## Added - Support first-party add-on metrics from Heroku Fir generation apps. - Support Heroku Fir host metrics. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Fix issue when running on CI 2025-11-21 · Elixir · phoenix 2.8.1 · [www.appsignal.com/changelog/elixir/2025-11-21-elixir-phoenix-2.8.1](https://www.appsignal.com/changelog/elixir/2025-11-21-elixir-phoenix-2.8.1) ## Fixed - Fix issue when running AppSignal for Phoenix in CI. When the `CI` environment variable was present, AppSignal for Phoenix would break during installation unless a separate environment variable was also present. View the [Elixir for Phoenix package v2.8.1 changelog](https://github.com/appsignal/appsignal-elixir-phoenix/blob/main/CHANGELOG.md#281) for more information. --- ## LiveComponent improvements 2025-11-20 · Elixir · phoenix 2.8.0 · [www.appsignal.com/changelog/elixir/2025-11-20-elixir-phoenix-2.8.0](https://www.appsignal.com/changelog/elixir/2025-11-20-elixir-phoenix-2.8.0) ## Added - Report LiveComponent traces and events separately from LiveView traces and events. Traces in AppSignal representing updates and event handlers in components will no longer be represented as calls to the view in which the component is mounted, and their events will be part of the `live_component` group. This makes it possible to obtain performance measurements for each component individually, instead of grouped by the view that mounts the component. - Group samples for calls to `handle_event/3` in LiveView and LiveComponent by the event that is being handled. View the [Elixir for Phoenix package v2.8.0 changelog](https://github.com/appsignal/appsignal-elixir-phoenix/blob/main/CHANGELOG.md#280) for more information. --- ## Disable collector host metrics by default 2025-11-19 · Collector · 0.8.0 · [www.appsignal.com/changelog/collector/2025-11-19-collector-0.8.0](https://www.appsignal.com/changelog/collector/2025-11-19-collector-0.8.0) ## Changed - Change the `enable_host_metrics` configuration option default from `true` to `false`. Host metrics are now disabled by default and must be explicitly enabled in the configuration. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html). --- ## Markdown support for status pages and MCP updates 2025-11-17 · App · [www.appsignal.com/changelog/app/2025-11-17-app-updates](https://www.appsignal.com/changelog/app/2025-11-17-app-updates) ## Added - Add support for markdown on the AppSignal status pages. You can now use markdown in the main description, and status updates. ![AppSignal Status page markdown example](/assets/changelog/2025-11/appsignal-status-markdown.png) - Add `get_triggers` MCP Tool. This tool exposes all the anomaly detection triggers and is in preparation for the create/update trigger tool. - Add `get_app_resources` MCP Tool. This tool exposes multiple application resources such as users, namespaces, and dashboards. It will be the home of application resources that do not need any additional filtering. ## Removed - Remove `get_users` MCP tool in favor of `get_app_resources`. - Remove `get_namespaces` MCP tool in favor of `get_app_resources`. --- ## Fix payload authentication issue 2025-11-07 · Collector · 0.7.2 · [www.appsignal.com/changelog/collector/2025-11-07-collector-0.7.2](https://www.appsignal.com/changelog/collector/2025-11-07-collector-0.7.2) ## Fixed - Fix an issue where the collector would stop transmitting data after a payload's authentication was rejected. This release can be installed through [our collector packages and Docker image](https://docs.appsignal.com/collector/installation.html).