Updates and product improvements
Two tags on a trace now link to a related page. Select the icon next to the tag to open it:
hostname: View host metrics opens that host's metrics around the time of the trace. In apps that report Kubernetes metrics, it is View pod metrics instead.revision: View deploy opens the deploy for that revision.
The links appear on error and performance traces. Read the trace page docs for every tag action.
The External notifications page now marks deprecated notifiers with a Deprecated label. Its tooltip says what to set up instead. The label appears on:
The deprecated PagerDuty and MS Teams notifiers can stop working at any time, so replace them soon. The Add new notifier list no longer offers them, so you can't set up a new one by mistake.
Read the Slack migration docs for what changes when you migrate a Slack notifier.
Notifier URLs must now be public. AppSignal only sends notifications to addresses on the public internet. It rejects webhook and other notifier URLs that point to localhost, a private network range, or another internal address. If an existing notifier points to one, AppSignal stops sending to it, and its log shows "Request blocked: URL does not resolve to a public address". Point the notifier at a public URL to start receiving notifications again.
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.
We had already announced how you can follow a failed browser request into your back end. 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.
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 to set it up. Tell us what you think in our Discord channel.
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.
Read the GitHub integration docs to learn more. This feature is part of AppSignal Labs.
The daily charts on the APM usage and Log usage pages now draw each day at its real height, so quiet days still show as short bars next to your busiest ones. Until now, one busy day could flatten the quieter days around it until they were hard to see.
A day's tooltip now opens from anywhere in that day's column, not only from the bar, so you can read the value of a small day too.
To find the charts, open your organization's settings and go to Subscription → APM usage or Log usage. Read the usage docs for what the charts show.
The Discover AppSignal page has a new side quest: Set an Apdex target. 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.
Apdex is part of AppSignal Labs. Read the Apdex documentation to learn how AppSignal scores your requests.
Tell us what you think in our Discord channel.
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 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.
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.
Tell us what you think in our Discord channel.
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.
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:
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.
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.
Our guides on reducing requests and reducing log volume 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.
See our upgrade policy for the full process and which accounts it applies to. If your usage pattern doesn't fit the policy well, email us and we'll look at it with you.
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.
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 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.
Distributed tracing is in beta as part of AppSignal Labs. Tell us what you think in our Discord channel.
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 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 for how the two actions run. Tell us what you think in our Discord channel.
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.
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, 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 for how each scope counts new errors.
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, 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 for what each trace shows. That page is also where distributed tracing shows its service map and timeline. Distributed tracing is in beta as part of AppSignal Labs.
Tell us what you think of trace logbooks in our Discord channel.
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.
You keep your current limits until October 31, 2026. That gives you two options:
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.
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.
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:
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.
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.
Select the query bar and a dropdown opens with two groups:
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.
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. Read the query syntax documentation for the syntax behind the editor.
Free for 30 days. No credit card. Two-minute install.
Need help or have a feature request? Talk to a real engineer. Not a bot, not a ticket queue.
AppSignal is built by a small, dedicated team spread across the world. We love stroopwafels. If you do too, let us know. We might send you some.
