Changelog

A pull request linked to an incident already shows whether it's open, closed, or merged. Now it also shows when your fix is deployed. Once a deploy ships the pull request, its badge in the incident's Actions panel changes from Merged to Live. You no longer have to check your deploys to know whether the fix is out.

• Hover over the button to see which deploy shipped the pull request, and when.
• The incident's logbook records the change from merged → deployed.

When AppSignal creates a deploy marker for a new deploy, it asks GitHub which commits the deploy added since the previous one. If a linked pull request was merged in one of those commits, it changes to Live.

AppSignal doesn't track every deploy, such as rollbacks or a deploy of more than 1,000 commits. Read the GitHub integration docs for what you need to set up, and the full list of what AppSignal doesn't track.

This feature is part of AppSignal Labs. Tell us what you think in our Discord channel.

MCP clients that first check for a newer MCP protocol version, such as ChatGPT, now fall back to the version AppSignal MCP supports. Until now, these clients could sign in but then failed to discover AppSignal's tools. ChatGPT showed Authentication succeeded, action discovery failed.

If your client showed this error, connect it to AppSignal MCP again. To connect AppSignal MCP in the ChatGPT desktop app, follow the OpenAI Codex setup.

You can now link a GitHub issue or pull request to an incident without leaving GitHub. Paste the incident's AppSignal URL in the description of the issue or pull request on GitHub, and AppSignal adds the link to the incident. This works alongside linking GitHub issues and PRs from a note on the incident on AppSignal, which starts in AppSignal.

The word in front of the URL decides how AppSignal records it:

• Linked: Fixes, Closes, Resolves, or no word. The issue or pull request is about the incident.
• Referenced: Refs, See, Related to, or cc. The issue or pull request only mentions the incident.

Linked and referenced issues both get a View #123 in GitHub button in the incident's Actions panel, with their status. The same words also work when you link an issue from a note, for example See acme/shop#123.

The logbook shows who added the link on GitHub. AppSignal only links the incident when the issue or pull request is in a repository of the same GitHub organization, or user account, as the repository connected to your app.

Read the GitHub integration docs to learn more. This feature is part of AppSignal Labs.

When your AI agent asks AppSignal MCP for a metric over time, it now gets data it can read more accurately:

• Missing data no longer shows as zero. Until now, a period without data looked the same as a value of 0. Your agent could tell you a metric dropped to zero when no data arrived at all. Now it can tell the two apart.
• A summary comes first. Each result starts with the time range and, for each metric, its peak, low, and average, and the periods without data. Your agent can answer from that without going through every value.
• Values come as a CSV table. A widely used format that agents and your own scripts can read reliably.
• You can choose the interval. Ask for values per minute, hour, or day.

If your own code reads the output of the get_metrics_timeseries tool, update it, because the format has changed. Read the MCP tool reference for details.

Deploy pages show the right deploy

The deploy page now shows the deploy whose revision matches exactly. Until now, if a revision was the start of a longer revision, the page could show the deploy of the longer one. If the revision no longer existed, the page crashed. It now shows Deploy marker not found.

Deploy pages for revisions that contain a dot, such as version numbers, also no longer return a not found page when you reload them or open their link directly.

Number charts no longer hide that they show a single value

A number chart shows one value. A wildcard (*) in its metric, such as hostname=*, matches many series: one for each host. The chart could show only one of them, without saying so, so you could mistake one host's value for the total.

The chart editor already blocked wildcards in number charts. Now the GraphQL API, AppSignal MCP, and the AppSignal CLI block them too, when you create or update a number chart. Number charts saved with a wildcard before this fix can still be updated, as long as the update doesn't add a new wildcard. Read the GraphQL dashboard mutations for more.

Host and pod inspect pages list the right hosts and pods

On the Host metrics page, you can select up to four hosts and select Inspect to compare their metrics. When you picked a custom time range there, the charts used your range, but the dropdown for choosing hosts listed hosts from a different time range. So hosts that reported during your range could be missing from it. The dropdown now uses your custom range. The page that compares Kubernetes pods had the same issue, which is now fixed too.

Now, the service map on an error trace shows the services that took part in that trace, and the calls between them. When one of those services reports to another app in your organization, the map now shows it by name. Until now, it showed as Unknown service.

You see this on the error trace page and in the browser error side panel.

The GraphQL API no longer accepts a separate severities argument for log views and log triggers. Put the severity in the query instead. Read more about the log query syntax.

This removes:

• The severities argument from createLogView, updateLogView, createLogTrigger, updateLogTrigger, and LogLineTriggerInput.
• The severities field from log views and log triggers.

Requests that still send or select severities now fail. AppSignal CLI versions before 2.2.1 do this, so upgrade to 2.2.1 or later. The schema has marked severities as deprecated since October 15.

Your saved log views and triggers keep working without changes. We already added their severities to their queries. On the Logs page and the log triggers page, you can also filter by severity in the query.

When you sign in with OAuth, you choose one organization and, optionally, the apps the token can reach. If you select no apps, the token reaches all apps in that organization, including apps you add later. So if you add apps often, you don't need to create a new token each time. The GraphQL API now applies that choice in two more places:

• Incidents and organizations: an OAuth token now only returns those from the organization and apps it was granted for.
• Apps: an organization's list of apps no longer includes deactivated apps.

The AppSignal CLI uses this API, so it only shows what you granted when you signed in. AppSignal MCP follows the same rules.

Read more about authentication for the CLI or AppSignal MCP.

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:

• Slack notifiers set up before the current Slack app. Select Migrate on the notifier's row to move it to the new Slack app.
• PagerDuty notifiers. Set up a PagerDuty V2 API notifier instead.
• MS Teams notifiers. Set up an MS Teams (Workflows) notifier instead.

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. Read the webhooks docs for details.

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.