Commerce observability – what should be measured before go-live?

In many e-commerce projects, the moment the platform is launched is treated as the end of the most important stage. The store is working, orders are going through, payments are connected, integrations have been tested, and the team can move on to the next activities: campaigns, offer development, promotions, SEO, marketplaces, automation, and sales optimization. From a business perspective, go-live therefore very often means moving from project mode to growth mode.

In practice, the real test of the platform only begins after launch. E-commerce stops being an environment controlled by the project team and starts operating under real traffic, with real customers, real integrations, real data errors, real delays in external systems, and real consequences of every failure. This is when it becomes clear whether the platform not only looks good and supports the standard purchase path, but also whether it is resistant to load, integration errors, task queues, API timeouts, payment issues, synchronization delays, incorrect product data, and non-standard purchase scenarios.

This is precisely why commerce observability, meaning the ability to understand what is actually happening across the entire sales ecosystem, is becoming increasingly important. It is not only about classic server monitoring, website availability, or Google Analytics reports. It is about visibility into the processes that affect sales: from the user entering the website, through product search, adding an item to the cart, checkout, payment, order saving, data transfer to ERP, stock level updates, transactional email handling, all the way to the synchronization of documents, statuses, and post-sales information.

OpenTelemetry defines observability as the ability to understand the internal state of a system based on its external signals, such as logs, metrics, and traces. In practice, this means that the system must be designed and instrumented in such a way that it emits data allowing us to understand not only that something has broken, but also where, why, and what impact it had on the user and the business.

For e-commerce, this is a very important distinction. If a company sees only a drop in sales, it is already too late. The customer has probably already experienced a slow store, a cart error, a payment problem, an outdated stock level, a discount code that does not work, or a missing order confirmation. Commerce observability makes it possible to detect such problems before they become visible in sales results, customer service tickets, or customer comments.

Why this topic is becoming important right now

Modern e-commerce is no longer a single application. Today, a sales platform is part of a broader environment in which ERP, PIM, WMS, CRM, payment systems, couriers, marketplaces, marketing automation tools, search engines, recommendation systems, analytics tools, data warehouses, headless frontends, mobile applications, and increasingly also AI solutions work together. Each of these elements may function correctly on its own, while the entire sales process may still be unstable.

This is one of the biggest traps in managing e-commerce after implementation. The server may be working. The homepage may be loading. The admin panel may be accessible. And at the same time, customers may be unable to place an order because the payment integration returns errors only for a selected method. They may see outdated stock levels because synchronization with WMS is delayed. They may abandon the cart because delivery calculation takes too long. They may not find a product because the search index has not been refreshed properly. They may not receive a transactional email because a task has become stuck in the queue on the email system side.

In such an environment, the classic question “is the store working?” is too simple. A much more important question is: “are the key sales processes working in the way expected by the customer and the business?”. Reliability does not mean only that the system is available, but that it does what the user expects from it. A very fitting example for e-commerce: the system may be available, but if clicking “Add to Cart” does not add the correct product to the cart, it is difficult to talk about actual reliability.

This way of thinking is particularly important in B2B. In wholesale sales, a technical problem rarely ends only with the loss of a single cart. If a business customer does not see the correct price, cannot place an order within their limit, does not receive a document, has no access to order history, or an integration with their purchasing system does not work, they may return to email, phone calls, or direct contact with a sales representative. At that point, the B2B platform stops relieving the team and starts creating additional work.

That is why, in the coming years, the advantage will belong not only to companies that implement a modern e-commerce platform, but to those that are able to consciously observe, measure, and develop it after launch. In a world of integrations, automation, headless commerce, AI, and agentic commerce, a lack of process visibility is becoming one of the biggest operational risks.

Monitoring, analytics, and observability are not the same thing

In many companies, monitoring is equated with someone checking website availability, server load, memory consumption, 500 errors, or application response times. These are important elements, but they are not enough to manage modern commerce. Monitoring tells us that something has exceeded a defined threshold. Observability makes it possible to understand what is happening throughout the entire process and how individual events are connected with one another.

E-commerce analytics is also not the same as observability. GA4, sales reports, campaign dashboards, and conversion data show the effects of customer behavior and business results. They are needed, but they often reveal a problem only after it has already affected sales. If conversion drops, the business sees the symptom. Commerce observability should help determine whether that symptom results from slow checkout, a payment error, a discount code that does not work, a cart issue, outdated stock levels, search engine errors, or a delay on the side of an external system.

Effective monitoring should focus first and foremost on symptoms experienced by the user, and only then on causes used for debugging. This is a very important approach for e-commerce, because from the customer’s perspective, it does not matter whether the problem comes from the database, cache, queue, payment API, or ERP. The customer simply sees that the store is slow, the cart does not work, or the order does not go through.

Commerce observability should therefore connect three levels. The first is the customer experience level: whether the user can find a product, add it to the cart, and place an order. The second is the business process level: whether price, availability, payment, delivery, documents, and statuses are correct. The third is the technical level: whether the application, API, queues, cache, database, search engine, and integrations are working stably.

If a company sees only the technical level, it may miss business problems. If it sees only sales analytics, it may react too late. If it sees only customer reports, it acts only once the problem is already visible externally. Observability combines these perspectives and makes it possible to understand e-commerce as a business-critical system.

The biggest mistake: measuring only what is easy to measure

The most common mistake is that a company measures what is most easily accessible, rather than what truly affects sales. It is easy to measure overall website availability, the number of sessions, average loading time, the number of orders, revenue, and conversion. It is harder to measure how many times delivery calculation failed for a specific group of customers, how many orders got stuck before being transferred to ERP, how many products had inconsistent stock levels, how many payments were not confirmed correctly, or how many times a user returned from checkout to the cart because of a validation error.

Meanwhile, it is often precisely these more difficult metrics that best show the true health of the platform. E-commerce may have high technical availability and at the same time lose sales because of problems scattered across systems. Checkout may work for most customers, but not for those using a specific payment method. ERP integration may work for most of the day, but experience delays during peak hours. PIM may synchronize product data, but omit some of the attributes required by filters or marketplaces. WMS may return stock levels, but with a delay that causes unavailable products to be sold.

This is why, in commerce observability, it is not enough to measure averages. Average response time may look good, but the most important purchase path may still be slow. The average error level may be low, but the errors may affect the most valuable B2B customers. Average conversion may decline only slightly, but the loss may concern a specific market, channel, delivery method, or promotion.

Good observability should make it possible to ask more precise questions. Does the problem affect all customers, or only logged-in ones? Does it occur in B2B or B2C? Does it concern a specific sales channel? Does it appear only for a particular delivery method? Does the error occur on the platform side, in an integration, in payments, ERP, WMS, or the frontend? Is the problem technical, related to product data, to the configuration of business rules, or to communication with an external provider?

Without such visibility, the company operates reactively. It sees the effects, but does not understand the causes. The business team reports a drop in sales, the technical team checks logs, customer service collects tickets, and integrators search for the problem in their systems. Everyone is looking at a fragment. Commerce observability should provide a shared picture.

What is actually worth measuring after e-commerce implementation

After implementing a platform, it is worth measuring not only infrastructure, but first and foremost the key sales processes. In practice, the most important elements are those that directly affect the ability to place an order, data correctness, and the quality of customer experience.

The first area is the availability and performance of critical paths. It is not enough to know that the website responds. You need to know how the category page, product page, search engine, cart, checkout, customer login, registration, B2B account, document download, and payment finalization work. It is worth measuring response time, the number of errors, the effectiveness of moving between stages, and differences between markets, devices, channels, and customer groups.

The second area is checkout. This is where technical errors very quickly become sales losses. It is worth measuring the number of attempts to proceed to payment, validation errors, failed payments, timeouts, delivery method errors, discount codes that do not work, login issues, interrupted sessions, and orders that were started but not saved correctly. In B2B, additional important elements include limits, roles, approvals, individual prices, product availability for the customer, and order compliance with commercial terms.

The third area is integrations. It is necessary to measure not only whether an integration “works”, but also delays, the number of errors, retries, duplicates, lost messages, state discrepancies, mapping errors, and processing time. Integrations with ERP, PIM, WMS, CRM, payments, couriers, marketplaces, and marketing automation tools are particularly important. Very often, they determine whether the platform is only a nice frontend or a truly functioning sales system.

The fourth area is product data and the catalog. It is worth measuring attribute completeness, PIM synchronization errors, products without images, products without required data, variant errors, indexing issues, filters that do not work, outdated prices, missing translations, and inconsistencies between channels. In modern e-commerce, catalog quality affects not only UX, but also SEO, marketplaces, AI, personalization, the Digital Product Passport, and B2B sales.

The fifth area is asynchronous processes. In Shopware, many tasks are processed asynchronously in a queue, which means they can be executed independently of timeouts or failures, and sample tasks include sending emails, indexing products, or generating sitemaps. This means that simply clicking in the panel or performing an action does not always mean that the entire process has already been completed.

The sixth area is post-sales service quality. Order confirmations, invoices, delivery statuses, returns, complaints, email communication, customer account updates, and document availability may not directly affect the purchase moment, but they do affect trust and operational efficiency. If a customer has to ask about an order status because the system did not send the information, a technical problem becomes a service cost.

Checkout as the most important observation point

If a company has to choose one process that it should observe particularly carefully, it should be checkout. This is where the frontend, cart, prices, promotions, taxes, delivery, payments, customer data, product availability, validation, integrations, and order saving meet. In B2B, individual price lists, limits, user roles, approval processes, customer order numbers, contract terms, and often ERP integration are added to this.

Checkout is the place where a small error can have a very concrete cost. If a payment method does not work for an hour, the company loses orders. If delivery is not calculated for a specific postal code, the customer will not complete the purchase. If the price in the cart differs from the price on the product page, trust decreases. If a B2B customer sees the wrong limit or incorrect terms, they return to the sales representative. If an order has been paid for but has not reached ERP, the problem moves from the frontend to operations.

Commerce observability should therefore treat checkout as a process, not as a single page. It is worth seeing how many people entered the cart, how many proceeded to the next step, how many tried to choose delivery, how many selected payment, how many started the transaction, how many returned with an error, and how many orders were saved correctly in the platform and transferred further. Only such a picture shows where the problem actually arises.

It is also very important to distinguish technical errors from business errors. A technical error is, for example, a payment timeout or an application exception. A business error is a situation in which a delivery rule returns no option, a promotion does not meet the conditions, the customer lacks permissions, the product is unavailable, or the limit has been exceeded. For the user, both types of errors may look similar: the purchase failed. For the team managing the platform, the difference is crucial.

In a well-designed e-commerce environment, checkout should have its own metrics, alerts, and root cause analysis. Not because technology is more important than marketing, but because marketing will not fix a process that does not allow the customer to buy.

Integrations as the most common source of hidden problems

In modern e-commerce, many problems do not arise within the platform itself, but at the points where systems connect. ERP integration delays order saving. PIM does not send complete product data. WMS returns stock levels with a delay. CRM does not receive a customer update. The payment system confirms a transaction, but the webhook is not handled correctly. A marketplace accepts an offer but rejects some products because of incorrect attributes. A courier does not return available delivery methods for a specific address.

These are problems that are difficult to detect using classic application monitoring alone. The server works, the application works, but the business process is interrupted. That is why integrations should have their own observability layer: communication statuses, response times, the number of errors, queues, retries, duplicates, unsuccessful mappings, data discrepancies, and reports on undelivered messages.

Monitoring delays is particularly important. In e-commerce, not every error is an immediate failure. Sometimes the bigger problem is that a process works, but with a delay. Stock levels update after an hour. Orders reach ERP after several minutes. Product data synchronize once a day, even though the team expects changes in near real time. A B2B customer sees an old price because the price list has not been processed. Such problems are deceptive, because the system formally works, but the business operates on outdated data.

This is precisely why integrations in e-commerce projects should not be treated as one-time connections. They should be designed as processes that can be observed, diagnosed, and developed. Shopware provides the Admin API for backend operations such as products, orders, customers, or batch processing through the Sync API, as well as the Store API for storefront interactions such as headless frontends, mobile applications, carts, checkout, and access to the sales channel. This provides a solid foundation for integrations, but the mere availability of APIs does not replace monitoring data flows.

In practice, every key integration should answer several questions. Was the data sent? Was it received? Was it mapped correctly? Was it processed? Did the result of the process return to the platform? Did a retry occur? Was the error handled automatically, or does it require human intervention? Without this information, the company operates on trust, not control.

Product data also requires observability

Product data is very often treated as a topic belonging to PIM, categories, or merchandising. Meanwhile, in modern e-commerce, the product catalog is one of the most important elements of sales infrastructure. If product data is incomplete, inconsistent, or delayed, problems appear in many places at once: in search, filters, SEO, marketplaces, recommendations, campaigns, AI, customer service, and B2B.

Commerce observability should therefore also include product data quality. It is worth knowing which products do not have required attributes, which have not been indexed correctly, which have incorrect variants, which do not have translations, which do not have images, which have not passed marketplace validation, which have discrepancies between PIM and the e-commerce platform, and which have been published despite missing data critical for sales.

In B2B, this topic is even more important, because product data is often linked to technical documentation, certificates, spare parts, product relationships, compatibility, units of measure, and individual sales conditions. If a business customer cannot find a product or does not trust its parameters, they will not always report an error. Very often, they will simply return to contact with a sales representative or choose another supplier.

Observability of product data should be connected with the publishing process. A product should not be treated as ready only because it exists in the system. It should meet specific quality requirements for a given channel, market, and customer type. A marketplace may have different requirements, a B2C store different ones, a B2B portal different ones, a technical catalog different ones, and future layers related to AI or the Digital Product Passport different ones still.

In this sense, observability does not concern only technical errors. It also concerns whether the data on which sales are based is good enough for the platform to function without manual support from the team.

Performance: not only website speed, but process speed

E-commerce performance is often reduced to page loading time. This is an important indicator, but it is not sufficient. A customer may enter a fast-loading website and then get stuck in a slow search engine, cart, delivery calculation, or payment. In commerce observability, it is necessary to measure the speed of entire processes, not only individual views.

In Shopware, performance may depend, among other things, on cache, search engine, indexing, database, queues, server configuration, integrations, and frontend behavior. Official Shopware documentation indicates that HTTP Cache makes it possible to cache system responses, so that when the same request appears again, the response can be returned faster, and the performance documentation notes that HTTP cache is an important element for production systems.

For stores with a large catalog, search and indexing are also particularly important. Elasticsearch in Shopware is a way to improve the performance of product and category search.

However, even the best performance configuration is not enough if the company does not observe how the system operates under real load. It is worth measuring not only average response time, but also times for the slowest users, differences between channels, the impact of promotions, load during peak hours, search execution time, cart processing time, delivery calculation time, and checkout completion time.

In e-commerce, slowdowns are rarely only a technical problem. A slow purchasing process may mean lost conversion. Slow data synchronization may mean incorrect stock levels. A slow admin panel may mean lower team efficiency. Slow queue processing may mean delays in emails, indexes, and post-sales processes. Performance is therefore part of both customer experience and operational efficiency.

Alerts that help instead of generating noise

Many companies have monitoring that generates too many alerts or alerts on the wrong things. If a team receives dozens of notifications per day, most of which require no action, they very quickly stop treating them seriously. On the other hand, the lack of alerts for critical processes means that the company learns about a problem only from the customer, customer service, or the sales department.

Good alerts in e-commerce should be connected to their impact on the user and the business. This approach is aligned with SRE thinking, Site Reliability Engineering, in which alerting should focus primarily on symptoms that matter from the user’s perspective, rather than only on technical causes.

This means that not every increase in CPU, Central Processing Unit, usage must wake up the team at night, but the inability to place an order certainly should. Not every single integration error requires an alarm, but a growing number of orders not passed to ERP should be detected quickly. Not every queue delay is critical, but a delay affecting transactional emails, product indexing, or availability updates can have a real impact on sales and customer service.

The best alerts are understandable. They should say not only that something happened, but also which process is affected, what the potential business impact is, and where diagnostics should begin. An alert saying “increase in API errors” is less useful than information that the number of errors in delivery calculation is rising for a specific sales channel. An alert saying “the queue is growing” is less useful than information that queue delay is affecting product indexing and the publication of a new offer.

Commerce observability is therefore not about measuring everything and alerting on everything. It is about building a visibility model that helps the team understand priorities faster. In e-commerce, the most important question is not only “what broke?”, but “can the customer buy, will the order be handled, and can the business operate without manually working around the problem?”.

Observability in B2B e-commerce

In B2B, observability is particularly important because sales processes are more complex, and problems are less obvious than in B2C. A business customer may have individual prices, delivery terms, user roles, limits, approval processes, access to selected products, order history, documents, recurring carts, offers, and an integration with their purchasing system. If any of these elements does not work, the platform does not fulfill its role.

In B2B, it is therefore necessary to observe not only overall conversion, but also the correctness of the customer context. After logging in, does the customer see the correct products? Are the prices consistent with ERP? Are the limits up to date? Do approvals work? Do people with different roles have the proper permissions? Do quick orders and shopping lists work correctly? Are documents available? Do orders reach the operational system with the correct numbers, terms, and contract data?

These are metrics that may be invisible in classic monitoring. The platform works, but the B2B customer sees an incorrect price. Checkout works, but it does not respect the approval process. The integration works, but it does not pass the customer’s order number. The customer account works, but it does not show the current document history. For the business, these are not minor errors. These are situations that determine whether the customer will use the platform or return to traditional channels.

In B2B, observing team relief is also particularly important. If the platform was intended to reduce the number of inquiries reaching sales representatives, it is worth measuring whether this actually happened. If the customer portal was supposed to reduce questions about statuses and documents, it is necessary to check whether customers use it and whether the processes work correctly. If quick orders were supposed to shorten the purchase time, it is worth measuring whether business customers actually complete orders independently.

Commerce observability in B2B is therefore not only a technical topic. It is a way of checking whether the platform is genuinely transferring the sales and customer service process into the digital channel.

The role of Shopware in building a visible and controlled ecosystem

Shopware fits well into an approach in which e-commerce is part of a broader ecosystem of data, channels, and integrations. Shopware has an open API-first architecture and the ability to integrate with the systems on which the business depends. This is important because observability requires not only an efficient platform, but also the ability to trace flows between systems.

API-first does not automatically mean observability, but it makes it easier to design an environment in which data and processes are available in a controlled way. If the platform communicates with ERP, PIM, WMS, CRM, a headless frontend, and external tools through well-designed APIs, it is possible to consciously measure response times, errors, volumes, delays, and process effectiveness. If integrations are accidental, manual, or undocumented, observability becomes much more difficult.

Shopware also includes elements that naturally require observation in larger implementations: message queues, scheduled tasks, indexing, cache, search, sales channels, APIs, checkout, integrations, and extensions. Scheduled tasks are used to plan tasks in the queue, while queues themselves make it possible to process background tasks such as sending emails, indexing products, or generating sitemaps.

This means that in a well-designed Shopware implementation, one must think not only about functions, but also about the visibility of how they work. Are queues being processed? Are tasks not piling up? Is cache functioning properly? Are indexes up to date? Is the Store API responding stably? Is the Admin API correctly supporting integrations? Does checkout work for all sales channels? Are extensions not negatively affecting performance?

Shopware provides a solid foundation, but the final quality of observability depends on the implementation architecture. The platform may be open and scalable, but if the company does not measure processes, document integrations, and design alerts, it will still operate reactively.

How CREHLER approaches commerce observability

At CREHLER, we look at e-commerce not only as an implementation project, but as a sales system that must work stably after launch. That is why observability should be part of the architecture conversation from the very beginning, not an add-on implemented only once the first problems appear.

In practice, this means that already at the design stage, it is worth defining which processes are critical to the business. In one project, this will be checkout and payments. In another, stock level synchronization. In yet another, ERP integration, B2B customer service, importing product data from PIM, search, marketplace, or the quotation process. Only once these priorities are known can the appropriate metrics, logs, traces, alerts, and dashboards be designed.

In Shopware projects, combining the technical and business perspectives is particularly important to us. It is not enough to know that the API returned an error. It is necessary to know whether that error concerned an order, a product, a customer, payment, delivery, price, document, or synchronization. It is not enough to know that the queue is growing. It is necessary to know whether it affects emails, indexing, statuses, integrations, or offer publication. It is not enough to know that checkout is slower. It is necessary to know whether the cart, delivery, payment, validation, order saving, or communication with ERP is slower.

This approach is especially important for companies developing B2B, cross-border, or headless e-commerce. The more channels, systems, and processes there are, the greater the risk that a problem will remain hidden between layers. Observability makes it possible to shorten diagnosis time and reduce the number of situations in which the customer is the first to see the problem.

At CREHLER, we help companies design e-commerce platforms so that they are not only scalable, but also maintainable, measurable, and ready for development. A well-designed Shopware architecture, integrations with ERP, PIM, WMS, and CRM, control over asynchronous processes, checkout monitoring, and product data quality observation are the elements that determine whether a platform, after implementation, will support growth or require constant firefighting.

From firefighting to predictable growth

A lack of observability means that the company operates reactively. The problem first appears for the customer, then reaches customer service, then the e-commerce manager, then IT, then the technology partner, and only after that does diagnosis begin. Each next step means time, frustration, and cost. In the worst case, the company does not even know how many customers experienced the problem, how many orders were not placed, and what the real impact on sales was.

Good commerce observability changes this model. The team sees that the number of payment errors is increasing. It sees that a specific integration is delayed. It sees that orders from one sales channel are not reaching ERP. It sees that a task queue is beginning to affect product indexing. It sees that checkout for B2B customers is slower after a change in pricing rules. It sees that product data from PIM does not pass validation for part of the catalog. Thanks to this, it can react earlier, before the problem becomes widely visible.

This is the difference between maintaining a platform and managing its quality. Maintenance answers the question of whether the system works. Observability answers the question of whether the system supports sales in a predictable way. In e-commerce, this difference has a direct impact on revenue, service costs, customer trust, and the pace of development.

Companies that invest in observability make development decisions more easily. They know which processes are stable, which require optimization, which integrations are risky, which channels generate problems, and which platform elements have the greatest impact on customer experience. As a result, e-commerce development stops being based only on opinions and reports and begins to be based on data about how the system actually works.

Companies that see more scale e-commerce faster

In modern e-commerce, it is not enough to launch a platform and measure sales indicators. It is necessary to understand how the entire ecosystem enabling that sales activity works. Product data, checkout, payments, integrations, queues, cache, search, order statuses, B2B accounts, documents, automations, and post-sales processes create one system. If the company cannot see how it functions, it cannot manage it consciously.

Commerce observability is therefore not a technological luxury. It is an element of e-commerce maturity. The greater the sales scale, the more integrations, the more complex the B2B model, the more markets and channels, the more important it becomes to detect problems quickly and understand their impact on the business.

The greatest advantage will belong to organizations that do not wait until the customer reports a problem. They will see the signals earlier: in metrics, logs, traces, alerts, integration processes, and operational data. They will be able to diagnose faster, fix faster, and plan development better.

At CREHLER, we help companies develop scalable Shopware-based e-commerce platforms that are ready not only for launch, but also for stable growth after implementation. If you want to check whether your platform makes it possible to detect problems before the customer sees them, it is worth starting with a conversation about architecture, integrations, data, and observability. This is where the difference begins between e-commerce that merely works and e-commerce that can truly be controlled.