How Moneat connects errors, logs, traces, and incident response

Checkout is failing. You need to identify the affected service, inspect the failure, and decide who needs to respond.

This walkthrough follows that investigation in Moneat, from the initial alert through the available error, trace, metric, log, and replay data. The scenario is illustrative rather than a measured incident. It also shows where configuration or missing telemetry limits what you can see.

The starting signal

Assume an alert reports a rise in failed checkout requests for the checkout-api service. The alert should answer three questions before anyone opens a chart:

• Which service and environment are affected?
• What condition crossed its threshold, over what window?
• Which route and responder own the next action?

If the alert lacks a service, environment, or stable source identity, fix that first. Correlation cannot reliably recover context that the source never supplied.

Inspect the error

Open the related errors for the service and time window. A useful error event contributes the exception type, application frames, release, environment, tags, breadcrumbs, and affected user context that your SDK was configured to send.

In this example, suppose the dominant issue is PaymentGatewayTimeoutException. That narrows the investigation, but it does not prove whether the gateway, network, database, or application caused the timeout.

Check grouping before using the event count as impact. A changed fingerprint or missing stack frame can split one failure across several issues, while an overly broad fingerprint can combine unrelated failures.

Follow the trace

If the error carries a trace ID and the relevant services emit spans, open the distributed trace. The trace can show where latency accumulated across the checkout API, payment client, database, and downstream services.

Look for the first unexpectedly long or failed span rather than assuming the final exception is the root cause. Compare attributes such as service, operation, status, deployment environment, and release.

No trace link means one of several things: tracing was not enabled, sampling excluded the trace, propagation broke between services, or the error and spans used different identifiers. The product cannot reconstruct a trace that was never captured.

Query the logs around the failure

Use the trace ID, service, environment, and time range to narrow the logs. Structured fields are more reliable than manually matching timestamps across unscoped text.

The logs might reveal a gateway timeout, a retry, or a database connection error. Treat that as evidence to compare with the trace, not an automatic conclusion. A log line written after a failure often describes the symptom rather than the initiating condition.

Logs link cleanly when the application includes the same trace and service context. Without those fields, you can still search by time and message, but the investigation requires more judgment.

Check metrics and replay where they add evidence

Service and infrastructure metrics can show whether the failure coincided with resource pressure, queue growth, dependency latency, or a deployment. Align the time range and dimensions with the error and trace before comparing charts.

For a browser checkout, a session replay may show the user action, network failure, console output, and visible result. Replay is useful for understanding impact and reproduction; it does not replace the server-side trace or prove causality.

Privacy controls also require configuration. Review masking, blocking, SDK data, and sampling for the application before enabling replay. Do not assume that every possible identifier or input is removed automatically.

Turn evidence into a response

Once the affected service and likely failure domain are clear, declare or update the incident and page the route that owns the next action. Carry the error, trace, relevant logs, time window, and current hypothesis into the incident instead of asking the responder to repeat the discovery.

The responder should still be able to challenge that hypothesis. A connected workflow reduces search and transcription; it does not make an uncertain root cause certain.

Use the incident timeline to record decisions, mitigations, ownership, and customer communication. After recovery, preserve the evidence that explains why the mitigation worked and create follow-up work for the underlying failure.

What makes the links work

Moneat can preserve and use correlation identifiers that arrive with telemetry. It cannot infer an identifier that was dropped between services or restore a signal excluded by sampling.

Reproduce this workflow with your telemetry

Start with one service and one controlled failure:

1. Send a test error with service, environment, and release context.
2. Confirm its trace propagates through the downstream request.
3. Add the trace ID and service fields to structured logs.
4. Verify the relevant metrics use the same service identity.
5. Capture a replay only if it adds client-side evidence, with privacy controls reviewed.
6. Trigger the alert and confirm the intended responder receives and acknowledges the page.
7. Record which links were automatic and which required a manual query.

That result is a useful baseline. It tells you what the next real incident investigation can rely on and what instrumentation work remains.

Connect a telemetry source | OpenTelemetry setup | On-call documentation