Changelog

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.

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 shows you how to connect your agent.

Tell us what you think in our MCP Discord channel.

Security

• Stop trusting certificates issued under the eMudhra intermediate certificate authorities whose private keys were compromised in October 2026. 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 for more information.

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.

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 explains both ways to authenticate.

Tell us what you think in our Discord channel.

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, 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 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 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.

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 for every tool and parameter.

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

POST /api/v2/metrics/list in the Public API (V2) 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.

The Limits page 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 describes the request format and shows an example.

Timeseries queries work as before. AppSignal MCP 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 explains why.

Tell us what you think in our Discord channel.

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), or ask your agent through AppSignal MCP. The uptime monitoring documentation explains what each phase measures.

Tell us what you think in our Discord channel.

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.

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 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.

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

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

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

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:

appsignal-cli auth login

Install it with Homebrew (brew install appsignal/appsignal-cli/appsignal-cli) or the install script, then read the documentation 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 for more information.

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.

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. Read the full blog post for more details.