Sentry in Magento 2

technical store observability with the Kowal_Sentry module

12 minutes, 47 seconds

Sentry in Magento 2

Sentry in Magento 2: technical store observability with the Kowal_Sentry module

What Sentry is and what it is actually used for

Sentry is most often associated with error tracking, but in practice it is an observability platform that combines several layers of application diagnostics:

  • exception and runtime error reporting,
  • performance tracing and relationships between operations,
  • breadcrumbs showing the sequence of actions before a failure,
  • Session Replay on the browser side,
  • User Feedback from the end user,
  • monitoring of recurring processes such as cron,
  • release tracking and linking errors to a specific deployment.

In a properly implemented project, Sentry is not just a place where a stack trace lands. It is a tool that lets you answer questions such as:

  • what exactly broke,
  • where the problem occurred: backend, frontend, checkout, cron, integration,
  • since when the problem has existed and which release it is associated with,
  • whether the error affects all users, a specific store, payment method, or process,
  • what the request context looked like and what happened right before the error.

This is especially important in Magento, where a failure is rarely an isolated exception in one controller. It often affects the whole flow: storefront, AJAX, checkout, payment provider, a cron synchronizing data, and later order processing.

Why Sentry is especially useful in Magento projects

Magento 2 is a large, layered platform with heavy integrations. A typical store works at the same time as:

  • a PHP backend application,
  • a frontend application with a lot of JavaScript,
  • an integration system connecting ERP, PIM, WMS, OMS, payment gateways, and couriers,
  • a multi-store environment with different scopes and configuration per website or store view,
  • a platform operating critical sales processes where a problem in checkout or cron has a direct effect on revenue.

In practice, this means a plain file log is not enough. A PHP stack trace alone is not enough either. Diagnosis requires a broader observation model:

  • backend exceptions with business context,
  • JavaScript errors from a real user session,
  • tracing of requests and HTTP dependencies,
  • cron and CLI monitoring,
  • correlation with the release after deployment,
  • data sanitization so observability does not conflict with security.

This is exactly the area where Sentry fits Magento well, provided the integration is implemented consciously and not as a simple wrapper around captureException().

How Sentry can be used in Magento 2

1. PHP backend error monitoring

The most obvious scenario is reporting PHP exceptions from storefront, admin, API, cron, and CLI requests. In Magento, this gives quick access to:

  • the stack trace,
  • environment and release,
  • route name and full action name,
  • store view context,
  • related customer, quote, order, or product data if the integration attaches it.

This makes it possible not only to see that an error occurred, but also to distinguish a checkout issue from an integration problem or an admin panel error.

2. JavaScript frontend monitoring

Many critical failures in Magento do not appear in PHP but in the browser:

  • a RequireJS error,
  • a problem with a Knockout component,
  • failed XHR in checkout,
  • an unhandled Promise rejection,
  • an error in a custom widget on the PDP or in the cart.

Sentry Browser SDK can capture this together with breadcrumbs, network requests, page URL, environment, and release. In practice, this gives a much better picture of what the user actually sees.

3. Performance Monitoring and tracing

Sentry can collect transactions and spans, which makes it possible to analyze:

  • HTTP request duration,
  • slow CLI commands,
  • long-running or unstable cron jobs,
  • external HTTP calls from the backend,
  • AJAX and fetch calls in the browser.

This does not replace full infrastructure-level APM, but in Magento projects it is very valuable diagnostically because it combines performance with application context and release.

4. Checkout monitoring

Checkout is the most important technical area of a store. This is where errors cost the most. Sentry can be used for:

  • recording errors in checkout steps,
  • tagging the payment and shipping method,
  • breadcrumbs for AJAX calls triggered by checkout,
  • analysis of placeOrder issues,
  • Session Replay for sessions ending in an error.

This translates directly into shorter diagnosis time for problems that affect conversion.

5. Cron Monitoring and check-ins

Magento relies heavily on cron. It handles many processes the user does not see directly:

  • exports and imports,
  • synchronizations with external systems,
  • alert generation,
  • data cleanup,
  • indexing and maintenance tasks.

Sentry makes it possible to monitor cron check-ins, their execution time, and status. This makes it easy to notice that a job has stopped running, runs too long, or ends with an error.

6. Release tracking and source maps

One of Sentry's biggest strengths is linking errors to a specific deployment. If the release is set consistently for backend, frontend, and source maps, the team can:

  • distinguish an old error from a regression after the latest deploy,
  • narrow down the scope of changes faster,
  • correctly symbolicate stack traces from frontend assets,
  • assess the impact of a specific release on store stability.

In Magento projects this is especially important because deployment often includes backend, static content, and integrations at the same time.

What the Kowal_Sentry module is

Kowal_Sentry is a production Magento 2 module that integrates the store with Sentry on both backend and frontend. It was designed as an integration layer aligned with Magento architecture:

The module is available here: Kowal_Sentry for Magento 2.

  • without modifying the core,
  • using dependency injection,
  • with plugins around key application entry points,
  • with configuration through Stores -> Configuration,
  • with backend and frontend separated,
  • with strong emphasis on data security.

It is not a single helper that sends an exception. It is a set of mechanisms combining the PHP SDK, Browser SDK, release strategy, context providers, sanitization, and monitoring of Magento processes.

How the integration works in our module

PHP backend bootstrap

The module initializes the PHP SDK once per request or process. During bootstrap it sets, among other things:

  • dsn,
  • environment,
  • release,
  • sample_rate,
  • traces_sample_rate,
  • profiles_sample_rate,
  • enable_logs,
  • send_default_pii,
  • before_send hooks,
  • hooks sanitizing breadcrumbs, transactions, check-ins, logs, and metrics.

This matters because right at the entry point the policy is defined for what may be sent to Sentry and what should be filtered out or redacted.

Transactions for HTTP requests

The plugin around Magento\Framework\App\Http wraps the request in a transaction of type http.server. The transaction is named based on the Magento request and receives tags and data such as:

  • route_name,
  • full_action_name,
  • request path,
  • HTTP method,
  • area_code.

If the request ends with an exception, the module reports it to Sentry and closes the transaction with an error status.

CLI monitoring

The plugin around Magento\Framework\Console\Cli starts cli.command transactions for bin/magento commands. This gives observability for:

  • reindexing,
  • imports,
  • manually triggered tasks,
  • custom integration commands.

In practice, this is very useful on staging and production, where CLI issues are not always visible in standard application monitoring.

Cron monitoring and check-ins

The plugin around Magento\Cron\Model\Observer starts a cron.job transaction, reports execution time, and sends check-ins to Sentry. This makes it possible to:

  • monitor all cron jobs or only selected job_code values,
  • set a timeout per job,
  • set a maximum expected runtime,
  • build consistent monitor names through a slug prefix,
  • optionally auto-register the monitor on the first check-in.

This is one of the stronger parts of the integration because it connects Sentry's technical monitoring with Magento's real operating model.

Checkout instrumentation

The plugin around Magento\Quote\Model\QuoteManagement::placeOrder() adds breadcrumbs and reports exceptions related to order placement. This allows the event to contain additional context, for example:

  • cart_id,
  • payment_method,
  • information needed for faster diagnosis of checkout failures.

On the frontend side, the module can additionally track checkout breadcrumbs and AJAX errors, which together gives a more coherent picture of the order flow.

Spans and breadcrumbs for HTTP calls via Curl client

The plugin around Magento\Framework\HTTP\Client\Curl adds an http.client span for GET, POST, PUT, and DELETE calls. It records, among other things:

  • URL,
  • method,
  • host,
  • response status,
  • a breadcrumb corresponding to the call.

This is useful when diagnosing integrations with external APIs, where the error does not come from Magento itself but from response time, an authorization problem, or an invalid payload on the partner side.

Browser SDK for storefront and admin

On the browser side, the module loads Browser SDK dynamically through Magento and RequireJS. Initialization includes:

  • dsn,
  • environment,
  • release,
  • tracesSampleRate,
  • Replay,
  • User Feedback,
  • tracePropagationTargets,
  • beforeSend with event sanitization.

Additionally, the module:

  • hooks into RequireJS errors,
  • adds AJAX breadcrumbs,
  • sets Magento tags and contexts,
  • initializes checkout instrumentation only on checkout_index_index,
  • can run on the storefront and optionally in admin.

Release strategy

Our module supports four release strategies:

  • manual,
  • env,
  • file,
  • generated.

In practice, this means the integration can be matched both to a simple manual deployment and to mature CI/CD. Additionally, the module supports environment variables such as:

  • KOWAL_SENTRY_RELEASE,
  • SENTRY_RELEASE,
  • RELEASE_NAME,
  • GIT_COMMIT.

If the release is not provided externally, the module can generate it based on the Magento version, module version, and commit short hash.

Sanitization and privacy

One of the most important parts of the integration is the event sanitizer. In our module, sanitization covers:

  • request headers,
  • cookies,
  • POST body,
  • query params,
  • contexts and extra,
  • tags,
  • user,
  • breadcrumbs,
  • logs,
  • metrics.

Depending on module configuration, it can:

  • block Authorization,
  • block cookies,
  • remove request bodies,
  • mask customer data,
  • anonymize IP,
  • redact additional sensitive keys such as token, api_key, customer_email.

In e-commerce this is not an add-on. It is a condition for a correct integration.

Module configuration scope

Configuration is available in the Magento panel:

Stores -> Configuration -> Kowal -> Sentry

The settings are intentionally divided into sections corresponding to different aspects of observability.

1. General

The base section controls module activation and shared parameters:

  • global enable or disable of the module,
  • Environment,
  • Release Strategy,
  • Release Name Override,
  • Project Name,
  • Debug Mode,
  • test CLI commands.

This section sets the foundation of diagnostics. Without a proper environment and release, data in Sentry is less valuable because it is harder to distinguish environments and deployments.

2. Backend SDK

This is where PHP-side monitoring is configured:

  • Backend DSN,
  • Error Sample Rate,
  • Trace Sample Rate,
  • Profile Sample Rate,
  • Enable Logs,
  • Enable Metrics API,
  • Enable Cron Monitoring,
  • Enable CLI Monitoring,
  • Enable Adminhtml Monitoring,
  • Enable API Monitoring.

This section determines whether the store reports backend exceptions and tracing, and how broad the observation scope is for processes running outside the storefront.

It is worth remembering that backend metrics in current sentry/sentry 4.24.x are treated as deprecated or no-op, so the Enable Metrics API field should be treated as a compatibility facade of the module rather than a full backend metrics pipeline.

3. Frontend SDK

The frontend section is responsible for Browser SDK:

  • Frontend DSN,
  • Enable Storefront JS,
  • Enable Admin JS,
  • JS Trace Sample Rate,
  • JS Replay Session Sample Rate,
  • JS Replay On Error Sample Rate,
  • Enable Session Replay,
  • Enable User Feedback Widget,
  • Enable Checkout Instrumentation,
  • Enable Ajax Instrumentation,
  • Browser SDK CDN URL.

This separation is very important. In many Magento projects, the observability needs of the storefront and admin differ, which is why the module lets you manage them separately.

4. Privacy / Security

This section defines the data security policy:

  • Send Default PII,
  • Anonymize IP,
  • Mask Customer Data,
  • Mask Checkout Fields,
  • Mask Payment Fields,
  • Block Authorization Headers,
  • Block Cookies,
  • Block POST Bodies,
  • Redact Query Params,
  • Additional Redacted Keys,
  • Replay Mask Selectors,
  • Replay Block Selectors,
  • Allowed Domains for Replay Network Details.

This is a critical section in every production implementation. Observability settings that are too permissive can lead to sending data to Sentry that should never end up there.

5. Filtering

The filtering section makes it possible to reduce noise:

  • regexes that ignore exceptions,
  • regexes that ignore URLs,
  • ignored transactions,
  • bot filtering,
  • health check filtering,
  • filtering part of admin traffic,
  • filtering part of static asset errors.

In a well-maintained project, filtering is not optional. Without it, the team quickly loses signal quality in Sentry.

6. Context

Here we define how much Magento business context is attached to events:

  • store context,
  • website context,
  • customer context,
  • quote context,
  • cart totals,
  • order context,
  • product context,
  • category context,
  • payment and shipping method,
  • module version,
  • Magento version,
  • deployment metadata.

This section is especially valuable in projects with a complex checkout and many integrations, because it lets you answer much faster who and what the problem affects.

7. Source Maps / Release

The release and source maps section organizes data needed for frontend release workflow:

  • source maps usage flag,
  • source maps upload mode,
  • Assets Base URL,
  • Release Dist,
  • Organization,
  • Project Slug,
  • Release File Path.

The module itself does not upload source maps during Magento runtime. And that is good. This should be done by the CI/CD pipeline, for example through sentry-cli.

8. User Feedback

The feedback section allows control over the browser-side widget:

  • widget theme,
  • language,
  • auto-open for selected errors,
  • presence on the success page,
  • presence on the contact page,
  • footer trigger,
  • custom trigger selector.

This function is useful where the team wants to collect signals from end users more quickly without building a separate technical issue reporting mechanism.

9. Cron Monitoring

The cron section organizes monitoring of Magento jobs:

  • automatic monitor registration,
  • list of monitored job_code values,
  • timeout threshold per job,
  • max runtime per job,
  • monitor slug prefix.

This matters because in practice not all cron jobs are equally critical. The module lets you focus monitoring on processes that have a real impact on sales, integrations, and store continuity.

What a sensible implementation scenario looks like

In practice, the recommended process looks like this:

  1. Start backend monitoring with a restrictive privacy policy.
  2. Add frontend monitoring for the storefront.
  3. Enable tracing with a moderate sample rate.
  4. Enable cron monitoring for the most important jobs.
  5. Configure a release strategy consistent with deployment.
  6. Add source maps in CI/CD.
  7. Only then extend Replay and feedback coverage.

This order makes sense because it lets you first build a stable and secure diagnostic signal, and only later increase data detail.

What this integration gives the technical team

From the maintenance team's perspective, a well-configured Kowal_Sentry provides very concrete value:

  • faster detection of failures after deployment,
  • shorter diagnosis time for checkout errors,
  • better visibility into HTTP integration problems,
  • monitoring of cron and CLI processes,
  • consistent backend and frontend context,
  • greater control over the quality of data sent to an external tool.

In Magento projects, this usually means less time spent manually reproducing an error and faster movement from symptom to cause.

Limitations worth knowing about

No observability integration is completely unconditional. In the case of our module, it is worth remembering a few things:

  • backend metrics in the current Sentry PHP SDK should not be treated as a full metrics pipeline,
  • User Feedback is sometimes marked in Sentry as beta or experimental,
  • Replay should be implemented carefully and always with strong masking,
  • overly broad sampling in production quickly increases data volume and cost.

These limitations do not disqualify the solution. They simply require conscious configuration.

Summary

Sentry in Magento 2 makes sense when it is implemented as a full observability layer, not only as a simple mechanism for sending exceptions. That is exactly what Kowal_Sentry is for. It combines the PHP backend, JavaScript frontend, tracing, checkout, cron monitoring, release strategy, and data sanitization in one coherent Magento module.

As a result, the technical team gets a real tool for maintaining and developing the store: with better error visibility, faster regression diagnosis, and greater control over the stability of the sales process.

Sources

  • Sentry for PHP: https://docs.sentry.io/platforms/php/
  • Sentry for JavaScript Browser: https://docs.sentry.io/platforms/javascript/guides/browser/
  • Sentry Session Replay: https://docs.sentry.io/platforms/javascript/session-replay/
  • Sentry User Feedback: https://docs.sentry.io/platforms/javascript/user-feedback/
  • Sentry Crons for PHP: https://docs.sentry.io/platforms/php/crons/
  • Sentry Environments and configuration: https://docs.sentry.io/platforms/javascript/configuration/environments/

Previous Next