In our third Release of 2025, you’ll uncover new ways to correlate data, debug critical bottlenecks, and streamline your workflow.

Over the last few months, we have been working on powerful new features and refinements for you; designed to give you more in-depth visibility, more automation, and smoother workflows.

We’ve added Performance Correlation in our service overview, so you can now spot dependencies and degradations system-wide at a glance.

To make troubleshooting smoother, Tracepoints can now be triggered automatically, along with further improvements that give you faster, more precise profiling results.

For Shopware users, we’re introducing powerful new debugging options for the HTTP Cache, while an improved Transaction Tagging API gives you cleaner, more flexible insights across all environments.

We expanded crawler monitoring for assessment of their impact on app performance.

We’ve also sharpened instrumentation:

– Magento 2 template insights for spotting hidden inefficiencies.

– HTTP Location header instrumentation for more complete visibility.

– Enhanced TYPO3 and AMQP insights, closing gaps in instrumentation.

On top of that, quality-of-life features like choosing the default organization shown right after login make everyday use simpler and more intuitive.

More correlation. Smarter insights. Smoother workflows. With this Release, you’ll be ready to track performance from every angle and resolve issues faster than ever.

Enjoy and see how Release 2025.3 helps you push your application performance to the next level.

Summary

• Correlation In Service Overview
• Trigger Tracepoints Automatically
• Other Tracepoint Improvements
• Debugging Capabilities for Shopware Cache
• Improved Transaction Tagging API
• Monitoring Crawler Impact
• Improved Magento 2 Template Insights
• HTTP Location Header Instrumentation
• Improved TYPO3 Insights
• Improved AMQP Insights
• Select Organization shown after Log-In

Correlation In Service Overview

Through the “Service Overview” feature, Tideways allows you to pinpoint performance issues in different parts of your application. But as these services are often still connected, comparing their performance directly can reveal hidden dependencies and system-wide slowdowns.

With the new ‘All’ option in the performance screen, you can now view and compare performance graphs across all services in your project at once.

Hovering over a timeslot will make the familiar detailed tooltip for that service appear, while the same timeslot is highlighted across all other charts, making cross-service correlations effortless.

• Documentation: Service Overview

Trigger Tracepoints Automatically

Tideways now allows to configure the automatic creation of tracepoints on a schedule for the transactions of a service that have the highest performance impact.

In the Project Settings, you find a new section “Tracepoints” that allows you to configure these automatic tracepoints.

This feature is currently limited to the current request-based plans only and for all these projects, an automatic tracepoint was created already that creates a tracepoint, including callgraph collection, for the highest impact transaction once a day.

Based on this regularly available call graph trace, Tideways can detect more bottlenecks automatically and provide you with fresh insights every day in the “Observations” tab.

Additionally, Tideways can store these traces via Callgraphs in the trace history with long-term retention, enabling you to compare call graph data months or even years apart—and clearly see where your code has regressed over time.

• Documentation: Tracepoint Configuration

Other Tracepoint Improvements

Callgraph Tracepoints Activated By Default

When creating a new Tracepoint, the “Activate Callgraph Profiler” checkbox is now toggled on by default, because we saw the majority of tracepoints were created with Callgraphs activated.

Start Again Button for Tracepoints

A completed tracepoint can now be restarted with the same settings and duration again, by clicking on the „Start again“ button.

Debugging Capabilities for Shopware Cache

For Shopware, Tideways will now also collect the context information influencing the page cache key, making it easier to determine why a specific transaction could not be served from the page cache.

Improved Transaction Tagging API

The \Tideways\Profiler API now includes new methods getTags(), addTag(), and removeTag(). These allow you to build up the list of tags incrementally at different stages of a transaction. For example, adding an “authenticated” tag during bootstrapping and a controller-specific tag later when the controller runs.

The page cache instrumentation, which automatically sets cached and uncached tags, received an in-depth rework. Instead of a Shopware-specific solution, it now includes direct support for Symfony’s HTTP cache, benefiting all Symfony applications and implicitly fixing some bugs within Shopware’s page cache support—for example around stale responses.

The cached and uncached tags added by the automated instrumentation and the Profiler::markPageCache*() methods will also no longer overwrite any other tags already set for the transaction.

• Documentation: Custom Tags
• Documentation: Page Cache Hit Rate API

Monitoring Crawler Impact

Crawlers, bots, and robots have always been an influential source of traffic on public-facing web applications, and with AI bots doing more and more work on behalf of users, this share is increasing recently.

To allow debugging performance issues caused by crawlers, Crawler Detection for traces was added in the 2024.3 Release of Tideways.

In this Release we are expanding its use into Monitoring: You can now see the percentage of crawlers in the current monitoring timeframe as a percentage and in the tooltip for each time slot. You can also see the crawler ratio in the history data at the daily, weekly, and monthly granularity.

Improved Magento 2 Template Insights

Information captured for Magento blocks has been extended. Block events now contain both the name and class name of a block instead of just a block, and new events for rendered template blocks have been added.

HTTP Location Header Improvements

Tideways will now store the redirect target (location response header) as an annotation on the root span.

This helps debugging and understanding in the cases where it’s important to know where exactly a request was redirected to.

Improved TYPO3 Insights

Tideways now includes automated instrumentation for TYPO3, including transaction naming, automated service detection, page cache tagging support, and Fluid Template spans.

• Documentation: Compatibility and Requirements
• Documentation: Supported Frameworks and Databases

Improved AMQP Insights

The existing AMQP instrumentation for both the amqp extension and the php-amqplib/php-amqplib composer library has greatly been extended.

• The timeline now includes spans for the connection establishment and opening a new channel.
• The publish command now includes annotations for the channel ID and improves reliability for the existing annotations for routing key and exchange name.
• For the amqplib composer library, time spent communicating with the AMQP service will now be tracked more accurately within the “Queue” layer.

Select Organization shown after Log-In

For users with access to multiple organizations, any one organization can now be marked as default by clicking on the star icon and will then be visible immediately after logging in.

For our first Release in 2025, we have cooked up more precise performance insights for you and can now, with Automatic Bottleneck Detection, serve you bottlenecks on a silver platter including recipes on how to fix them. Work on several improvements, like Native Worker Support in the PHP Extension, has kept us busy over the winter. A series of instrumentation improvements has chased away the winter blues and is now making way for a spring full of user-friendliness. We also present you with improvements to the Layer Monitoring and a new Notification Log. As part of the spring-cleaning, we renamed the traces that are compared with each other from Base/Target to Before/After. And that’s by no means all there is to report — dive head first in our Release and enjoy!

Summary:

• Automatic Bottleneck Detection
• Native Worker Support in PHP Extension
• Layer Improvements
• Notification Log
• session_write_close() in Timeline
• Trace Comparison: Base/Target is now Before/After
• Show muted errors in the UI
• Keep User-Agent for crawlers in trace metadata
• Instrumentation improvements

Automatic Bottleneck Detection

A profiling trace in Tideways has a lot of information across Timeline and Callgraph data, and finding bottlenecks usually means diving deep into this data. In the current Release, we introduce a more comprehensive automatic bottleneck detection that is based on the data from traces that we already collect. Instead of having to dig out the bottleneck from the profiling data yourself, if it’s a known problem, we can now show you both the bottleneck AND a solution recipe. Our goal is helping you accelerate bottleneck detection and troubleshooting.

With this foundation, we plan to add automated detection for even more bottlenecks specific to certain frameworks, such as Shopware, Symfony, or Magento. This customization will bring clarity more quickly, as it expedites the process of performance optimization by saving you the time-intensive search for solutions yourself.

So far, detected bottlenecks were displayed only in ‘Traces’ listed in the ‘Bottlenecks’ tab. Now, the bottlenecks will not only be way more detailed; they will also be aggregated to the service level and shown in ‘Observations’. You will get a complete overview in the observations tab and don’t need to sift through individual traces anymore.

Our new bottlenecks can also leverage Callgraph traces. So if you collect Callgraphs regularly, we will be able to gain even more insights into where your system is slowed down. Whilst we are expanding this feature, we incorporate everything we know about PHP performance into bottlenecks.

For now, we have added automatic detection for these new bottlenecks:

• Not using Composer Autoload Optimizations
• Using Symfony’s trigger_deprecation excessively
• Using Shopware’s CartPersister API incorrectly for a huge performance hit
• Blocking page views by using the Facebook Graph API to track Events 

• Documentation: Detect Bottlenecks in Traces
• Documentation: Observations with Bottlenecks

Native Worker Support in PHP Extension

Tideways now automatically detects transaction names for individual tasks executing within worker queues of Symfony, Laravel, Shopware 6, Magento, and WoltLab Suite.

In this Shopware 6 demo application, you can see the worker tasks individually monitored.

Native support for workers improves observability for requests that dynamically perform multiple independent (background) tasks with differing performance profiles.

Previously, Tideways would only detect the execution of a single long-running request, with the collected data and timeline showing the actions of all executed tasks. By automatically detecting the individual tasks and creating separate transactions, Tideways now can clearly attribute individual actions (e.g., SQL queries or HTTP calls) to the specific task, measure the failure rate of individual tasks and point out bottlenecks on a per-task basis. This also enables setting tracepoints on these individual tasks. 

Besides the supported worker queues listed above, we also plan to add more generic support and other frameworks in the future.

• Documentation: Instrument CLI Scripts

Layer Improvements

Additional Layers

While Tideways can already account for much of the time in a request when looking at our performance chart, there is still more to cover. With the following new layers, we can now provide an even more fine-grained summary of where the time is spent processing a request. 

As a result, there is less ‘Unaccounted Wait’ because more time spent waiting can be accounted for; that means more time is assigned to actionable layers. 

The layers are displayed in the averages chart in the performance section and in each trace (see layer report):

New Layer: Waiting for CPU

One of the Additional Layers is ‘Waiting for CPU’. It indicates the time spent waiting for the operating system’s scheduler to free up a CPU core to continue processing the request. It provides an indication that particular requests are experiencing delays in processing that are not necessarily caused by the request itself, but insufficient hardware resources or other processes, such as a database running on the same server, performing computationally expensive processing.

• Changelog: New Layer “Waiting for CPU” improves on “Unaccounted Wait”
• Documentation: What do this Metrics and Numbers mean?

Layer Report: a high-level breakdown of your traces

The first thing you see when you open a trace now is a complete, detailed layer report, a breakdown of all the layers that contributed to the total time of that trace.

Improved Layer Collection

As part of the improvement of the layer functionality, we did not just add additional layers and improved the UI, we also cleaned up the technical basis that collects the layer information within the Tideways extension. 

As a result, the collected data is more precise. For example, async HTTP requests using CurlMultiHandle now measure the time that is spent processing the retrieved data. 

Previously, the entire time from sending the request until the full response is received was measured, which would consider the sum of the runtime of parallel requests, exceeding the actual time spent blocking. 

Notification Log

We added a new ‘Notification Log’ for Errors/Exceptions, Incidents, and Releases. For each of these events, users can now view the date and time of the notifications and through which channel, e.g. Slack or email, they were notified.

session_write_close() in Timeline

Tideways will now indicate with a timeline marker when session_write_close() is used, indicating the time the session is unlocked. This can help other requests to go on without further ado.

When using PHP’s integrated session functionality, sessions are automatically locked for concurrent access while they are in use by a request to prevent race conditions. As a result, requests using the same session are blocked until previous requests finish. When no additional modifications to the session data need to be made, for example in read-only requests, the session_write_close() function can be used to write the updated session data and unlock the session, allowing other requests to proceed without waiting for the request to finish. Similarly to the existing marker for fastcgi_finish_request().

• Detecting Bottlenecks: Blocking Session

Trace Comparison: Base/Target is now Before/After

Previously, we used ‘Base’ and ‘Target’ as names for two traces that were to be compared with each other. This technical reference has now been altered in favor of a temporal perspective. Using ‘Before’ and ‘After’, the naming is now solely based on the chronological order of both traces. ‘Before’ for the older trace and ‘After’ for the newer one. Regardless of the comparison direction, the traces retain their names. It can be Before ⇒ After or After ⇒ Before.

Why do two traces differ in speed? By comparing them, you can detect why. A comparison of two traces can also make optimizations visible. Does the change I initiated make a difference, regarding speed? This question can be answered by making use of the trace comparison.

Show muted errors in the UI

The action ‘Don’t Notify’ for Errors/Exceptions was renamed to ‘Mute’ or ‘Unmute’, and in addition you can now see this in the UI with the crossed-out microphone icon.

Keep User-Agent for crawlers in trace metadata

Since Tideways Release 2024.3, Tideways recognizes requests performed by crawlers and adds a ‘Crawler’ tag. For requests tagged ‘crawler’, the full User-Agent will be available on the root span of a trace, allowing you to take action if an undesired crawler makes excessive requests to expensive routes.

Instrumentation improvements

As always, this Tideways Release includes a number of assorted improvements and bug fixes to the existing instrumentation functionality.

• The experimental MongoDB instrumentation added in Tideways 5.7.0 replaces the old MongoDB instrumentation as of 5.15.0. The new instrumentation is more reliable and provides better insights into the commands used.
• Each MongoDB command span now has peer.host and peer.port annotations, indicating the exact server the command was sent to. The mongo.service annotation on the “connect” span was removed, since the MongoDB client dynamically detects the cluster topology, making this information misleading.
• MongoDB: Logical conjunctions, such as ['field' => ['$gt' => 0, '$lt' => 10]] are now correctly reported in the mongo.filter annotation.
• HTTP requests performed using cURL multi now unconditionally collect a stack trace when calling curl_multi_add_handle(), pointing towards the location where the request is actually initiated, instead of the curl_multi_exec() event loop.
• Collect Shopware DAL spans in the EntityRepository instead of the EntitySearcher to catch more cases.
• A new swdal.criteria.title annotation is available on Shopware DAL spans, containing the result of Criteria::getTitle().
• The instrumentation for colinmollenhour/credis, which amongst others, is used by Magento now supports the tideways.features.redis_keys feature.
• Add the cached tag to pages returned from Magento’s page cache.
• Add automated service detection for WoltLab Suite’s ACP.
• Symfony Messenger transactions now include a span for each message handler.
• Improve Callgraph for Doctrine, by disambiguating calls to UnitOfWork::createEntity(), allowing to measure hydration performance per entity type.
• Instrument Symfony’s ErrorHandler component, allowing to see Exceptions handled by it in Tideways.

You can see these changes listed by PHP extension version on the changelog page.

Get the cake, Tideways is turning ten!

Exactly on this day ten years ago, we lifted the veil on Tideways’ predecessor and thus began our exciting journey that continues to this day.

We would like to celebrate by presenting interesting new features to you.

Summary:

• Differential Flame Graph
• Share Trace Comparison
• Dynamic Instrumentation for Functions from the UI
• Transaction Failure Rate Alerts
• IDE Integrations
• Improved Stacktraces from Third Party Libraries
• FrankenPHP Support
• WoltLab Suite Support

You can also watch a recording of our webinar on the topic, where Benjamin connects all these new features into a small story of improving a Shopware 6 plugin.

Differential Flame Graph

Differential Flame Graphs are a visual representation of a comparison between two sets of profiling data and is a beneficial tool for quickly identifying the root causes of performance problems. To benefit best from the findings, in Tideways they are presented in a comprehensible comparison box which shows the comparison base and the target, a summary and an example span. Unlike before, it’s now possible to see at a glance why a trace has become faster or slower.

It’s useful for instance to check whether a change in the source code, a system update or a configuration change improved performance or brought about a regression. It’s also possible to compare traces from different time periods or of different system states.

The color code depicts the most common way Differential Flame Graphs are presented. Red colors, alert you to an increase in execution time or resource usage. Blue, on the other hand, depicts a decrease. There are different shades of blue and red to depict minor or major decreases and increases. Neutral colors mean that no significant change has occurred.

Our Differential Flame Graph is interactive; you can hover over or click on the different areas to get more specific information.

The high level of detail helps to find an unwanted outlier in time or memory consumption faster.

Changelog: Differential Flame Graph

Share Trace Comparison

The comparison of two traces can now be shared with persons who don’t have a Tideways account or are not members of the respective organization. This is an immensely helpful addition to the existing feature that already allowed the sharing of a single trace.

You can click the share action directly from a trace comparison and share a link to it. That makes investigating performance problems and validating improvements much easier.

When sharing a trace in Slack or in other chat / social media tools, a preview is generated to offer the message receivers a summary:

Changelog: Share Trace Comparison

Dynamic Instrumentation for Functions from the UI

Dynamically instrumented functions are a new feature within Tideways to improve Profiling data and in turn identify performance problems even faster.

Previously, instrumentation was either defined within the Tideways extensions and could be added by changing the code to use the attribute #[WithSpan]. Now you can add instrumentation to your functions by simply clicking the “Dynamically Instrument Function” button from the callgraph interface. 

No changes in your application code or deployment of a new version needed!

Documentation: Instrument Functions from the UI

Changelog: Dynamically Instrument Functions

Transaction Failure Rate Alerts

What failure rate is acceptable for individual transactions? To find out what causes errors in one specific transaction, a failure threshold can be set for each individual transaction. The failure threshold is based on a list of predefined percentages and can be configured via the transaction settings page. 

To that end, you can set up a notification under “Project Settings > Notifications”. You then get notified via Slack or email or other supported integrations when the failure rate for a transaction increases and it needs attention to be resolved. 

For more details on how to configure it view our documentation.

IDE Integrations

You can now use the “Open in IDE” icon in Errors and Callgraphs. This makes it easier to directly switch from Tideways into the code and start fixing a bug or performance problem.

At the moment you can configure this integration for PhpStorm and VSCode. For third party libraries you can also directly jump to the code on GitHub without the need to configure anything.

For more details view our documentation.

PHP Extension:

Improved Stacktraces from Third Party Libraries

For libraries such as Doctrine, Guzzle and Laravel, stacktraces in the Timeline Profiler are now modified to show primarily frames from your code-base and not from the library. Before, due to the limiting of the stackframes size they sometimes included only frames from the library itself and no indication where in the application they occurred. Relevant ones were sometimes cut off. Now, the stacktrace is cut off to show primarily application-code function calls.

In addition we reduced the default duration for a span to keep its stacktrace from 5ms to 3ms and increased the number of stacktraces Tideways keeps per trace across plans.

FrankenPHP Support

Tideways is the first APM solution that fully supports FrankenPHP, including worker mode. Starting from PHP extension 5.8.0, Tideways supports FrankenPHP.

Worker mode only loads your framework once into memory. Subsequently, it sends requests to the same instance of your application and doesn’t spin up a new instance for every new web request. 

That means that one gives up the shared nothing of for example PHP-FPM or even FrankenPHP without worker mode but saves time and optimizes performance. 

For more details on how to use FrankenPHP with Tideways see our changelog entry and our documentation.

WoltLab Suite Support

Tideways now also includes instrumentation of WoltLab Suite out of the box. The Tideways PHP Extension will automatically detect which type of page of your community has been accessed to automatically fill in the transaction name, making the collected data useful without requiring manual changes on your end.