Changelog

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 for more information.

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 for more information.

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.

Move to a paid plan before October 31, 2026 and get 25% off your first year. Email 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, and we'll help you pick one.

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.

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 for more information.

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.

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.

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.

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 to set it up, or the Ruby specifics for the integrations that carry the trace for you. Part of AppSignal Labs.

If you read metric data through the GraphQL API, move those queries to the Public API (V2). 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 already queries the V2 endpoints.

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 for the full list of tools and parameters.

The Slack app is newly rearchitected, with two-way sync. It joins the other beta features in AppSignal 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 for setup and for migrating an existing Slack notifier, and tell us how it goes in our Discord.

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. Every organization has access to it. Read the Apdex documentation to set your thresholds, and tell us about it in our Discord channel.

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.

Two features we announced earlier this year have changed stage.

Dark mode is now generally available. It has left AppSignal 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.

Read about the Labs stages

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 locally, we recommend moving to the hosted endpoint. Read the MCP documentation to get set up.

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 for more information.

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 for more information.

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 for more information.

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 for more information.

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 for more information.

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 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 for more information.