Metrics: Pick a User-Facing Signal

Updated 8 October 2026 · Practical guide for small websites and applications

A healthy CPU chart does not tell you whether a visitor can open an article, submit a form or finish signing in. Choose measurements around the action that matters to the reader. This guide uses a fictional contact form to show how to turn a vague complaint—“the website is slow”—into a useful investigation.

1. Define what a successful action means

Write one sentence before choosing a monitoring tool: “A visitor submits the contact form and receives confirmation that the message was accepted.” A button click alone is not success. A page that displays a success message after a failed request is not success either. Decide where the application can reliably record acceptance, and distinguish this from eventual email delivery.

For a blog, start with article loading or search. For a repair booking service, start with booking submission. Measure one journey well before adding charts for every page.

2. Record volume, failures and duration together

• Volume: how many attempts occurred in a stated time window?
• Failures: how many attempts failed according to your definition?
• Duration: how long did the operation take, and where did timing start and end?

OpenTelemetry provides instruments for these measurements: counters accumulate events, gauges describe a current reading, and histograms collect distributions such as request durations. Its exporters send measurements to a monitoring destination. These instruments support a monitoring design; they do not decide what success means for your website.

3. Work through a small example

Suppose a contact form receives 200 submission attempts in an hour, and 12 fail. The failure rate is 12 ÷ 200 × 100 = 6%. If the next hour contains only 10 attempts and one failure, its rate is 10%. That percentage is higher, but it comes from a much smaller sample. Display the count beside the percentage before drawing conclusions.

Now imagine 95 of 100 successful submissions finish in 0.2 seconds while five take 8 seconds. The average is 0.59 seconds: ((95 × 0.2) + (5 × 8)) ÷ 100. That average hides a frustrating experience for five visitors. Inspect the duration distribution and high percentiles alongside the average. Percentile calculations and estimates vary between tools, so use the same method when comparing releases.

All figures here are illustrative, not measurements collected from Bagale Pulse.

4. Separate server time from the visitor's experience

A fast server response can still accompany a slow page because of a large image, delayed script or unreliable connection. Conversely, a slow database operation can delay every visitor regardless of connection speed. Keep server request duration separate from browser page-loading measurements. Give each chart a clear label and unit.

Test the same action on a phone and a computer, and compare Wi-Fi with a mobile connection when available. Record the page, time, device and whether the problem repeats. These observations help narrow the investigation; one device test cannot establish performance for all readers.

5. Keep metric labels useful and limited

Use a small set of labels such as operation, environment and outcome. Avoid attaching email addresses, form messages, session tokens or individual user IDs to metric labels. Apart from privacy concerns, unique values create many distinct series. OpenTelemetry documents this as cardinality: the number of unique attribute combinations tracked by a metric.

6. Decide what you will do when a signal changes

For each alert, record its owner, the action to investigate and the condition for clearing it. An alert that repeatedly fires without anyone knowing what to do becomes noise. Choose thresholds from your service needs and observed traffic, rather than copying an unexplained percentage from another website.

After a deployment, compare equivalent periods and note changes in traffic volume. If failures increase, check the failing operation and relevant logs before assuming the deployment caused it. If evidence points to the change, use your tested rollback procedure and verify that visitors can complete the action again.

A monitoring note you can reuse

• Journey: contact form submission.
• Success: the server accepts the message and the visitor sees confirmation.
• Window: one hour, with shorter windows for active investigation.
• Signals: attempts, failures, failure percentage and duration distribution.
• Context: release time, device observations and known service interruptions.
• Next action: investigate the failing step, record the cause and verify recovery.

Further reading: OpenTelemetry's official metrics documentation explains instruments, exporters and cardinality. The worked example and contact-form checklist above are explanatory examples developed for this guide.