Observability for a small ecommerce team: alerts you'll actually read

Most observability advice is written for teams with a platform group and a monitoring budget to match. Run an ecommerce site with a handful of people and much of it becomes a liability: every dashboard you add is something you now have to read, and every metric you export is a line on a bill. Here is how we keep monitoring genuinely useful — and very close to free — on a live marketplace: a small set of business metrics with disciplined labels, alerts that fire only when a customer is affected, and one hard rule about cost.

What observability means when you are five people, not fifty

At small scale the goal is not total coverage. It is answering four questions fast: is checkout taking money, is search returning results, did the last deploy break anything, and are we about to run out of disk or budget. Everything else is noise until it isn't. The failure mode that quietly kills small teams is alert fatigue — a channel that pings forty times a day trains everyone to ignore it, and the one page that mattered scrolls past with the rest.

It helps to separate two words people use interchangeably. Monitoring watches known things and tells you when a number crosses a line. Observability is being able to ask a new question about production without shipping code first. A small team needs a little of the first and a cheap version of the second. You do not need distributed tracing across a dozen services to run a marketplace; you need to be able to reconstruct one order's journey through the logs when a customer emails.

Metrics, logs, traces — and which you can skip

The three classic signals have very different cost and value profiles, and treating them as equally important is how monitoring bills balloon. Decide deliberately which ones earn a place.

Traces are the line item most small teams over-buy. If your services already write a shared request id into their logs, you can answer nearly every "where did this slow down" question by grepping, not by paying to ingest every span. Session replay earns its own budget because it catches a class of failure metrics and logs are blind to — we cover that in session replay for ecommerce.

Business metrics with enum-bounded labels

The metrics worth emitting on a store are business events, not machine internals: orders placed, search zero-result rate, cart-to-checkout ratio, ingest-job outcome, email-send success. Emit them as plain counters and gauges from the code path that already knows the truth.

The rule that keeps the bill flat is about labels. Every label attached to a metric must draw from a bounded, enumerated set of values. A label with unbounded values — a raw search string, a product id, a user id, a full URL — mints a brand-new time series for every distinct value it sees, and time-series databases both price and slow down on the number of series they hold. So coerce each label to a known enum: a fixed list of vendor identifiers, HTTP status classes, a handful of page-type buckets. Anything unexpected folds into an other bucket rather than spawning a series. A single unbounded label on one busy endpoint can turn a free-tier metric into a runaway cost overnight.

A free-tier-first stack

You can run real observability on free tiers if you stay disciplined. A pull-based metrics registry scraped into a hosted dashboard's free plan; logs shipped to a log store's free allowance with alert rules defined on patterns. Keep retention short — most incidents are diagnosed within hours, not weeks, so paying to store a month of debug logs is money spent on comfort. Prefer OR-ing many log patterns into one alert rule over creating many separate alarms, because on some platforms the alarm itself is billed. Our standing rule is simple: new monitoring goes to a free tier first, and any change that would move telemetry onto a paid surface needs a written cost estimate before it ships.

Alerts you'll actually read

An alert nobody acts on is a dashboard that interrupts you. Four rules keep the signal high:

• Alert on symptoms, not causes. Page on "checkout error rate above threshold for five minutes", not "CPU at 90%". High CPU with a healthy checkout is not an incident; it is a graph.
• Every alert is actionable and owned. If no one knows what to do when it fires, it is not an alert yet — write the runbook line first, or downgrade it to the digest.
• Two tiers only. Page for customer-facing breakage — checkout down, search returning 5xx, site unreachable, disk near full. Everything else lands in a once-a-day digest that a human skims with coffee.
• Route log patterns to rules. One rule can OR together the error signatures that matter, so a new failure shape becomes one small edit rather than a new paid alarm.

Deploy-aware alerting and the weekly review

A brief burst of 5xx that lines up exactly with a deploy restart is almost always the restart, not a regression. Annotate deploys on your graphs so whoever is triaging at 2am sees the correlation in a glance, and give restart-shaped blips a short grace window before they page. Around the automated alerts, keep a human cadence: a weekly read-only sweep of production — firing alerts, uptime, error rates, headroom, ingest health, order flow, recent deploys, cost anomalies — recorded in the same findings log every week, so nothing discovered ever silently disappears. That review is the junior-SRE job nobody staffs at a small company; because it is a checklist, an agent can run it reliably, which is a pattern we lean on across our AI-run operations.

The same discipline applies to the AI features on a modern store, where an unwatched token counter is the equivalent runaway — a topic we go deep on in LLM cost optimization. And the numbers your monitoring should surface first are the commercial ones, which is where an owned analytics stack and business dashboards meet observability.

Frequently asked questions