Engineering guides / Angular applications and AWS infrastructure
By Arte Soft engineering · 24 October 2026
Application observability that explains a failed customer journey
Observability is useful when it helps answer why a customer’s operation failed. A large dashboard full of unrelated graphs does not necessarily provide that answer. Begin with one important journey and follow it across the browser, API, background work and external services. Then decide which measurements can explain delay, failure and recovery without collecting unnecessary personal information.
Choose the question first
A product team may need to know why a translation stopped, an import never completed or a payment did not update access. Define the expected outcome and the points where the work changes hands. Add a correlation context that can connect relevant events without putting account secrets or content into logs. Decide what an operator should see when investigating a report. This prevents the common pattern of collecting every available field and discovering later that the useful request identifier was omitted. It also limits the privacy and storage burden of indiscriminate instrumentation.
Use signals for different purposes
Metrics help reveal rates and distributions, traces follow individual operations across boundaries, and logs record useful discrete events. They should complement each other rather than duplicate every payload. Distinguish a user cancellation from a system error and a retry from a new business operation. Track dependency latency so a frontend symptom can be traced to the appropriate service. When using OpenTelemetry, establish consistent names and attributes instead of inventing a separate vocabulary in each component. Instrumentation should be reviewed as part of the application, because misleading telemetry can send an incident response toward the wrong cause.
Test the investigation path
Create a controlled failure and ask someone to identify the affected operation using only the proposed tools and runbook. Can they see the failing dependency, distinguish a duplicate attempt and determine whether the user needs to retry? Deliver the instrumentation, dashboard or queries, alert rules and data-retention choices together. Acceptance should include redaction checks and a known error scenario. Avoid treating every exception as a page to an operator; alert on conditions that require an action. Where sampling is used, explain its limits so the absence of a trace is not mistaken for proof that an event never happened.
Keep a small glossary for operational terms such as accepted, completed and failed. If the API and background worker use those words differently, a support operator can misread the telemetry even when every service emits technically valid events.
Keep the cost and ownership visible
High-cardinality labels and verbose payload logging can increase expense quickly. Set retention and sampling according to the value of the investigation, and document who responds to alerts. Arte Soft’s own applications provide practical examples of multi-step user journeys, not a claim that all incidents can be prevented. Bring one recurring support complaint and your current logs. A scoped observability engagement can connect that complaint to actionable evidence. The objective is a shorter route from report to explanation, with enough context to fix the problem and without turning monitoring into another unmanaged product.
Relevant Arte Soft work
GPT Realtime Assistant — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Observability implementation and review?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft