Datadog · Observability explained
What is observability? The meaning, the three pillars and real examples
What is observability? It is the ability to understand what is happening inside your systems by looking at what they report about themselves: their metrics, logs and traces. A monitored system tells you that something is wrong. An observable one also lets you find out why, including for failures nobody predicted. This guide explains the meaning in plain words for managers and in more depth for engineers, shows how observability differs from monitoring, walks through three examples, and sets out how a Saudi IT team can start without buying more tooling than it needs.
Published 9 min read
Orientation
At a glance
The page in one table, for the reader with five minutes.
- Observability definition
- The ability to explain a system's internal state from the data it emits, including for problems nobody planned for
- The three pillars
- Metrics, logs and traces; most teams add a fourth signal, events and changes
- How it differs from monitoring
- Monitoring checks known conditions and alerts; observability lets you ask new questions of the same data
- Who needs it most
- Teams running many connected services, where incidents are hard to explain
- What it is not
- A single product, or a reason to collect every log line forever
- Where Interkey fits
- Assessment, instrumentation and operation of Datadog, with support from Riyadh
In short, for managers
- Observability is a property of your systems, not a product you install.
- It shortens the hard part of an outage: the time spent working out what is wrong, which is usually longer than the time spent fixing it.
- Data costs money to keep, so the goal is the right data for the questions your teams ask, not all data.
- You probably need it when a customer-facing service depends on several systems and incidents end with "we are still not sure what happened".
What is observability? The meaning in plain words
The word was borrowed from control engineering, where a system is called observable if you can work out its internal state from its outputs alone. In software, your applications, databases, servers and networks are the system, and their outputs are the telemetry they emit: numbers, records of events, and the path each request takes. If that telemetry is good enough, an engineer can explain what the system is doing without logging in to each machine or waiting for the failure to happen again.
Read more
A simple test helps. Think of the last incident that took a long time to close. Could someone have answered, from data already collected, which customers were affected, which service slowed down first, and what changed just before? If the answer needed guesswork, a new release with extra logging or the one engineer who remembers how it was built, that part of your estate is not yet observable.
So the observability meaning is practical: can we explain any behaviour of our systems from the data they already send us? No estate is fully observable; the work is to make the parts that carry the business observable enough, at a cost the organisation accepts. Our observability implementation hub covers how that is delivered; this page stays with the idea itself.
Observability vs monitoring: related, not the same
The two words are often used as synonyms. Monitoring is watching for conditions you already know matter: disk nearly full, error rate above a threshold, a service not answering. It answers one question well: is something we expected to go wrong going wrong?
Observability covers the questions you did not write a rule for. A payment page is slow only for customers on one mobile network. A nightly job finishes on time but produces wrong totals. Latency rises every Thursday at 14:00. None of these trips a standard alert, because nobody predicted them. Answering them needs data detailed and connected enough to be sliced in a way nobody planned.
Read more
In practice the two work together. Monitoring decides when a person is called; observability decides how quickly that person finds the cause. A team with strong monitoring and weak observability gets paged reliably and then spends hours in the dark. The aim is both, designed as one programme.
The three pillars of observability, and the fourth signal
The three pillars of observability are metrics, logs and traces. Most teams add a fourth, events and changes, because many investigations start with "what did we change?".
| Signal | What it is | The question it answers | Its usual limit |
|---|---|---|---|
| Metrics | Numbers measured over time: request rate, error rate, latency, CPU, queue depth | Is this healthy, and is it getting worse? | Shows that something changed, not which request or which customer |
| Logs | Timestamped records written by applications and systems when something happens | What exactly happened in this one case? | Volume grows fast and usually decides the bill; free text can carry personal data |
| Traces | One request followed through every service, database and call it touched | Where did the time go, and which hop failed? | Needs instrumentation inside the application, not only around it |
| Events and changes | Deployments, configuration changes, scaling actions, incidents | What did we do just before it broke? | Cheap to collect, and often the first thing teams skip |
The value comes from linking the signals: a latency spike on a dashboard, the traces of the slow requests behind it, the log lines those requests wrote, and the deployment that went out ten minutes earlier. When those links exist, an investigation becomes a few clicks. Our page on distributed tracing goes further into traces.
Observability examples: three incidents, with and without it
These are illustrations of common patterns, not stories from named clients.
1. A checkout that is slow for some customers
Customers say online payment is slow, but average response time looks fine. Without observability, the team restarts services and waits. With it, an engineer filters requests by response time, sees that the slow ones all call one external payment service from one region, and opens a trace showing the time spent waiting on that call. The fix is a timeout and a ticket to the provider, not a night of restarts.
Read more
2. A batch job that finishes on time and is still wrong
Finance reports that yesterday's totals do not match, yet the job ran normally. Without observability, someone reads code for a day. With it, the job's logs carry a record count per step and the change history shows a schema update to a source table the evening before. The investigation starts from the change, not from the code.
3. A mobile release that raises errors for one group of users
After a release, support hears of failures it cannot reproduce. Without observability, the release is rolled back on suspicion. With it, errors split by app version and operating system point to one combination, and traces show which API call fails. The team fixes that path and keeps the release.
The common thread is not a clever tool: the data needed for an unplanned question was collected, tagged consistently and linked before the incident started.
Why observability matters for IT teams in Saudi Arabia
Three things make the question sharper in the Kingdom. First, online services depend on chains of systems: a portal, an identity service, a payment provider, a core system, often a cloud region. When one link slows down, users see the whole service as broken.
Second, telemetry is data. Logs and traces can carry user identifiers and national ID numbers, so where they are sent is a data residency question. Datadog, for example, is SaaS: data lands on the Datadog site chosen when the account is created, and as of November 2026 none of its sites is in the Middle East. Many Saudi estates therefore filter or mask sensitive fields inside the Kingdom before anything leaves; our guide to observability data residency covers the designs.
Third, cost. Collecting everything is the fastest way to an unexpected bill, usually because of logs. Deciding what to keep, and for how long, is part of observability; see log cost control.
Relatedguide to observability data residencylog cost control
How observable are your systems today? A short self-check
Pick one service that matters to the business and answer these with the people who support it. The answers show where to start.
| Question | If yes | If no |
|---|---|---|
| Can you list the systems this service depends on, from data rather than memory? | You have a service map to build on | Start with tracing or a dependency map for this one service |
| Does every log line carry the same service, environment and version tags? | Logs can be filtered and joined to metrics and traces | Agree tagging rules before adding more data |
| Can you follow one slow request from the user to the database? | Traces are in place where they count | Instrument the request path, starting with the slowest journey |
| Does each alert name a symptom users feel, with a link to the data behind it? | Alerts lead to answers | Rewrite alerts around user impact before adding new ones |
Before you choose an observability tool
Settle these first; they decide platform, cost and timeline more than any feature list:
- The services that matter most, named and ranked.
- The questions your teams ask during incidents, written down.
- Where telemetry may be stored, agreed with your security and compliance owners.
- A tagging standard for service, environment, version and team.
- A data budget: what to keep in full, what to sample, and for how long.
- An owner after go-live, so dashboards and alerts stay current as systems change.
Where Datadog fits, and where it does not
Interkey is an official Datadog partner in Saudi Arabia; it sells licences, implements and supports the platform. Datadog collects metrics, logs, traces and events in one place, links them through shared tags, and adds products for application performance, infrastructure, real users, synthetic tests, databases and networks. For a team that wants the three pillars joined without running the platform itself, that is the main reason to choose it. Our Datadog page describes what we deliver.
Read more
It is not the answer to every case. A single application with a small support team may need better logging and two good alerts, not a platform. Data classes that may not leave the Kingdom need masking before sending or a store that stays inside, designed before the licence. And no tool fixes missing instrumentation or untagged data, which is why vendor-neutral instrumentation such as OpenTelemetry is worth considering early.
Interkey has worked in Saudi enterprise IT since 1999. Our engineers work from Riyadh, write runbooks and dashboards in Arabic and English, and stay with your team after go-live.
How Interkey helps a team become observable
-
Pick the services that matter.
Two or three customer-facing services, and the questions asked during their last incidents.
-
Assess what is collected today.
Signals, tags, gaps, residency limits and what the current tools cost.
-
Instrument and tag.
Agents, integrations and tracing on the request paths, with one tagging standard.
-
Build the views people use.
Service dashboards, alerts on user impact, and change events beside the graphs.
-
Operate and widen.
Review data volume and alert quality, then extend to the next services.
Questions managers and engineers ask about observability
How would you explain observability to a non-technical manager?
It is how well your team can answer "why is this happening?" from data the systems already send, without guessing. Monitoring tells you a service is unwell; observability helps you find the cause quickly.
Are three pillars of observability enough, or are there more?
Metrics, logs and traces are the three pillars most people name. A fourth signal, events and changes such as deployments, is just as useful, because many investigations start with "what changed?". Some teams add user-experience data from browsers and mobile apps.
Our monitoring already sends alerts. Why would we need observability as well?
Alerts cover the failures you predicted. If incidents still take hours to explain, the gap is in the data behind the alerts: missing traces, untagged logs, no record of changes. Observability closes that gap; it does not replace alerts.
Can a Saudi organisation use a SaaS observability platform for sensitive telemetry?
Often yes, with design. Datadog, for example, has no site in the Middle East as of November 2026, so sensitive fields in logs and traces are usually masked or dropped inside the Kingdom before sending, or kept in a store that stays inside. Which classes may leave is decided with your compliance owner.
How long does it take to make our main services observable in KSA, and what drives the cost?
It depends on the number of services, how they are built, how much is already instrumented and your residency limits, so we estimate after a short scoping, not before. Cost is driven mainly by hosts, data volume (logs especially) and retention, plus the implementation work; we quote licences and services together.
Is OpenTelemetry the same thing as observability?
No. OpenTelemetry is an open-source standard and toolset for producing and sending telemetry. Observability is the outcome: explaining your systems from that data. Instrumentation written once with OpenTelemetry can feed different platforms, Datadog included.
Next
Related pages
Next step
Ask how observable your systems are
Tell us which service matters most, what your teams use to investigate incidents, and whether any telemetry must stay in the Kingdom. We will suggest a first assessment step.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia