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.
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.
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.
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 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.
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. Define a query against any log source, choose a metric type, and AppSignal extracts the value during ingestion.
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 MCPmanage_log_line_action tool are visible there too.
A dark theme for the AppSignal UI is now available as part of AppSignal 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.
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.
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. Read the full blog post for the complete breakdown.
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.
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.
Once configured, open any app code line from an exception backtrace directly in your local editor.
Before setup, the option is available in the extras menu, accessible via the there dots icon.
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.
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.
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.
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.
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 to get started.
Don’t let the bad bugs bite. Try AppSignal for free.
AppSignal offers a 30-day free trial, no credit card is required. All features are available in all plans. Start monitoring your application in just a few clicks!