Improving AppSignal, one deploy at a time.
This release can be installed through our collector packages and Docker image.
View the Ruby gem v5.0.4 changelog for more information.
preload_app!. Before this change, applications running several forked processes would lose data points or report incorrect values for them.View the Ruby gem v5.0.3 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.
This release can be installed through our collector packages and Docker image.
service.instance.id and a process.pid of its own, which is what AppSignal uses to tell them apart.View the Python package v1.9.1 changelog for more information.
Use the revision set by Heroku, Render, Kamal or Scalingo when the application also has a REVISION file. Since version 4.6.0, a REVISION file took precedence over the HEROKU_SLUG_COMMIT, RENDER_GIT_COMMIT, KAMAL_VERSION and CONTAINER_VERSION environment variables, so an application that kept a placeholder REVISION file in source control reported that placeholder as its revision. The revision config option and the APP_REVISION environment variable still take precedence over both.
Thanks to @rmm5t for their contribution!
View the Ruby gem v5.0.2 changelog for more information.
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.
This release can be installed through our collector packages and Docker image.
response_status counter with a service tag. Response statuses can then be graphed per service when several services report to one app.View the Ruby gem v5.0.1 changelog for more information.
opentelemetry.sdk._logs, which is deprecated and is removed in a future release of the OpenTelemetry SDK. Its replacement is in opentelemetry.instrumentation.logging.handler.A log message that is not a string, such as the dictionary in logger.info({"message": "Order placed", "order_id": 1234}), is sent as text by the logging instrumentation. Pass the structured values in the extra argument to send a structured log line:
logger.info("Order placed", extra={"order_id": 1234})The OpenTelemetry logs API sends a structured log line from a dictionary body.
Ensure that data sent for check-ins, to an external collector, or via the agent always honors the http_proxy configuration option and the APPSIGNAL_HTTP_PROXY environment variable first, falling back to the HTTP_PROXY and HTTPS_PROXY environment variables if the configuration option is unset, and always ignores the NO_PROXY environment variable.
Fix local traffic to the AppSignal agent being incorrectly sent to an external proxy when the http_proxy configuration option is set in agent mode.
Improve handling of the extension internal queue when full.
Fix issues in the extension that lead to gaps in data reporting.
Logs are now still sent after your application configures the logging module. logging.config.dictConfig(), logging.config.fileConfig() and logging.basicConfig() keep AppSignal's log handler attached, so a configuration that sets its own handlers on the root logger, such as Django's LOGGING setting, will now send its logs to AppSignal as well.
If you have manually added an OpenTelemetry log handler to your LOGGING setting or to the root logger elsewhere, it should now be removed, as AppSignal's handler will now send those log lines as well, causing them to be sent twice. AppSignal will log a warning when it detects a redundant OpenTelemetry handler.
When disable_default_instrumentations is used to disable the logging instrumentation, prevent the log lines emitted internally by AppSignal from propagating to a manually configured OpenTelemetry handler in the root logger.
logging.basicConfig() applies the log level it is given. An application that calls it with a level below WARNING, such as logging.INFO, starts sending its log lines at that level.
Fix an issue where AppSignal would configure redundant handlers when starting again in a forked process, such as when a Celery worker calls appsignal.start() from the worker_process_init signal.
View the Python package v1.9.0 changelog for more information.
message tag.View the Elixir package v2.18.1 changelog for more information.
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.
Automatically instrument Broadway library.
Broadway is an Elixir library for building concurrent and multi-stage data ingestion and data processing pipelines.
When Broadway processes one or more messages, a trace is created to represent
the processing of these messages. Independent root spans encompass the call to
prepare_messages/2 and handle_message/3.
This instrumentation is enable by default and only available for Broadway versions higher than 1.0.0.
View the Elixir package v2.18.0 changelog for more information.
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.
View the Elixir package v2.17.7 changelog for more information.
ModuleNotFoundError: No module named 'requests' on Python 3.10 or later.View the Python package v1.8.1 changelog for more information.
View the Ruby gem v5.0.0 changelog for more information.
View the Elixir package v2.17.6 changelog for more information.
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.
