B2B commerce sites have a peculiar observability profile. The traffic is low compared to consumer storefronts — a few hundred sessions a day, often fewer. But each request is high-stakes: a quote that fails to load, a checkout that errors silently, a price that’s briefly wrong. The customer is a known business with a relationship, and "it broke for me" gets reported through their AR contact, not an anonymous review.
That mix changes what observability needs to do. Here’s what we run on B2B commerce projects, ranging from "small ASP.NET Core deployment on IIS" up to "multi-region hosted Sana Commerce."
The three things you actually need
- Structured logs you can search. When a customer reports an issue, you need to find every log line related to their session in seconds, not by tailing files.
- Distributed traces across the integration boundary. Most B2B commerce errors are in the seam between the storefront and the ERP. A trace that spans both is the difference between an answer and a long debugging session.
- Dashboards your sales-ops team can read. Not just engineers. When the VP of Ops asks "are we losing orders this week?" the answer should not require an engineer.
What we actually run on ASP.NET Core projects
Logging: Serilog with structured properties
Default ILogger via Microsoft.Extensions.Logging is fine, but Serilog gives you better structured logging with less ceremony. The setup we use:
- Console sink (visible in the Kestrel terminal during dev, in IIS stdout in prod)
- Rolling file sink in App_Data/logs (with retention — usually 14 days locally, with a job that pushes older files to durable storage)
- Enrichers for ClientIP, UserAgent, RequestId, and (when authenticated) the corporate-account identifier
The non-obvious enricher: customer/company ID. When you’re investigating "why did Acme Manufacturing’s checkout break," you want to grep on their ID, not on session IDs you have to look up first.
Tracing: OpenTelemetry
OpenTelemetry is the right answer for distributed tracing in 2026. ASP.NET Core has first-class OTel support; the setup is a few AddOpenTelemetry() calls plus an exporter (we typically use OTLP to a collector, then to Honeycomb / Jaeger / Application Insights / etc., depending on what the client already runs).
The high-value spans:
- HTTP server (every request)
- HttpClient calls to BuiltWith, the AI provider, the ERP, the email service
- SQLite / SQL Server query spans
- Custom spans around business-critical work — “evaluate price for customer X SKU Y,” “sync customer N to ERP”
Health checks
ASP.NET Core has a clean health-check API. We expose /healthz with checks for: filesystem write access (App_Data writable), SMTP reachability, and — most importantly — ERP connection or vendor APIs the storefront depends on.
The deploy pipeline polls /healthz after each deploy with retries; if it’s degraded after rollout, the pipeline fails loudly.
The dashboards that matter
The right number of dashboards is small. We typically build three:
- "Is the site working right now?" A single-pane view: HTTP error rate (last hour), p99 latency, ERP-sync error count, last successful sync timestamp. Refreshes every 30s. Lives on a wall in the office or pinned in a Slack channel.
- "Are orders flowing?" Hourly count of orders placed, dollar value, by channel. Sales-ops cares about this. So does AR. So does the CEO during launch month.
- "Investigation: customer name" A parameterized dashboard you open by typing a customer ID. Surfaces every action that customer’s users took in the last 30 days, every error that touched their account, every ERP sync involving their record. This is the dashboard you’ll wish you had the first time a customer says “something happened yesterday.”
Alerting that doesn’t cause alert fatigue
For B2B sites with low traffic, page-on-error alerts fire constantly because individual errors look statistically significant. We tune for these patterns instead:
- Sustained HTTP 5xx rate > 2% over 10 minutes (not single requests)
- Any failed health check that lasts > 1 minute
- ERP sync hasn’t succeeded in > 30 minutes (the silent killer)
- Order placement > 30 minutes without one going through during a window when there should be — measured against a 30-day baseline
Everything else: log it, dashboard it, don’t page on it.
What about Application Insights / Datadog / etc.?
Use what the client already runs. Application Insights is great if they’re Azure-heavy. Datadog is great if they have multi-cloud. Honeycomb is excellent for traces. The platform matters less than committing to a single one and keeping logs/traces correlated across it. The worst pattern is "we have logs in IIS, traces in App Insights, errors in Sentry, and SQL queries in nowhere" — three tools you toggle between to investigate one bug.
The takeaway
B2B observability is unglamorous and high-leverage. The actual work is small — a few hours of Serilog setup, a few more for OTel, a day for the customer-investigation dashboard. The payoff is the difference between “a customer called us about a problem yesterday and we don’t know what happened” and “here’s the trace, here’s the cause, here’s the fix going out today.”
If your B2B platform is in production and your debugging story is “tail the IIS log,” talk to us. We’ll have the dashboards in week one.