This is both a “reference number” story and an observability story. The two are the same story, really.
I’m trying to log into a mobile app. The SMS arrives with a reference number in it. But no matter what I do, the login never completes. Here is the interesting part: that number appears nowhere in the app, only in the SMS.
From a UX standpoint that is a gap; the user cannot verify which transaction they are in.
Why a reference number is an observability problem
From an engineering standpoint, something more important is lost. If that reference number is mapped to a correlationId on the backend, it becomes a correlation key. Which user, which flow, which step they got stuck on — the answer is right there. If it is wired into your logs and traces, the person on call finds the problem in a single query, and either a hotfix or a prioritised operational task follows. If it is not, that number is just a useless string sitting in the user’s pocket.
One more detail: the person who noticed this failure was a user. Me. That is what happens when a critical flow like login has no synthetic monitoring. A user telling you about an outage is not feedback; it is the bill for missing measurement.
Observability does not happen without shared infrastructure
This is not a new opinion for me. I worked on the marketplace side at Pazarama and Beymen Merchant, and on the lending side at Bondora and Riverty (formerly Arvato Financial Solutions). I also spent a period as an architect somewhere none of this existed: two teams, two separate monitoring tools, no shared infrastructure, no centralised logging. Investigating an issue meant searching logs server by server, and most of the time there was nothing left to find. When buying a new product came up as the solution, I pushed back; the problem was not a license. I proved it more than once, but who cared? That is a separate story — let us call it “The CTO Paradox”.
I have written around the same theme before, in technical vision and developer tools and in test environments that are as reliable as production. All three come down to the same thing: invisible foundations.
Seven questions to ask before talking about tooling
I like asking slightly awkward questions before the conversation turns to tooling:
- When a flow breaks, who finds out first — the team or the user?
- Are logs collected in one place, or still sitting on the servers?
- Do you have defined SLIs and SLOs? How did you verify the accuracy of the data on your dashboards?
- Can you follow a user’s flow end to end through a correlationId, traceId or sessionId?
- Does an alert reach a person, or a channel nobody reads?
- Is anyone actually on call? Do you practise incident management and write post-mortems?
- When the same failure happens a second time, does time to resolution go down?
The answers to those seven questions say far more than which observability tool you bought. Tooling makes a team with answers faster; it does not fill the gap for a team without them.
None of it works without an open-mic culture
Where I work now I can answer these questions, because I trust my team; they ask the right questions and look for the right answers. A few days ago we spotted a serious problem on the Hepsiburada side before our customers did. Not because of an extraordinary tool, but because the observability, on-call and incident management muscles are working.
None of this is possible without an open-mic culture. If you know how to collect feedback from customers and, more importantly, from your own people, there is very little you cannot do. The person who spots a failure earliest is usually not the most senior one; it can even be the person picking that item in the warehouse. Where what that person says can turn into an alert, observability is already half built.
Observability is not a line item on a license. It is a matter of ownership, engineering discipline, and being able to speak up.