- Decide first
- 1. Residency
- The question
- Where may telemetry physically land, per data classification? Logs especially.
- What it eliminates
- Everything. If telemetry must stay in-Kingdom, SaaS platforms without an in-Kingdom control point are out, whatever their features. Worked through here.
The observability practice
Observability consulting in Saudi Arabia
Interkey helps application, infrastructure and platform teams design observability around the systems they already operate: hybrid estates, Kubernetes workloads, existing telemetry pipelines, and the data residency obligations that shape all three in this market.
In short
Observability implementation, delivered in the Kingdom
Interkey designs, implements and operates enterprise observability for organisations in Saudi Arabia. The work covers instrumenting applications, infrastructure and logs; building dashboards and alerting that operations teams act on; and deciding where telemetry may land before the platform is chosen. It is platform-aware rather than platform-tied: the same four deliverables apply whether the answer is a hosted product or a stack you run yourself.
Read more
It is addressed to platform, infrastructure, application and IT operations teams in enterprises and telecom operators — the people who will own the result — and to the technology leaders funding it. If you are choosing a platform, recovering one that is already deployed and ignored, or deciding who operates it after go-live, this page is written for that decision.
The gap
The question nobody in this market answers
A Saudi platform team evaluating observability can find the vendors easily enough: their documentation is excellent and their marketing is everywhere. What it cannot find is the layer underneath: who implements this in the Kingdom, what a rollout actually involves on a hybrid estate, where the telemetry physically lands and whether that is acceptable, and who operates the platform at 3am Riyadh time once the integrator has left.
Read more
That layer is this practice. Interkey designs and implements observability for Saudi enterprises, then operates it or hands it over properly, and it publishes how it thinks, including the awkward parts, because the buyers this page is written for are engineers who can tell the difference.
One thing to be clear about immediately: the platform Interkey implements is Datadog. The decision framework below eliminates by constraint before any product name appears, and where the constraints point away from a SaaS platform, Interkey says so in public.
When this is the wrong fit: one application, one deployment and a support rotation of two people does not need an observability platform. It needs better logging and a phone that rings. This work starts paying when nobody can say, during an incident, which of eleven services caused it — and keeps paying when the answer has to be found by someone who was not on the original build.
RelatedInterkey says so in public
Terminology, settled
Two words this page uses precisely
Common question
Is observability different from monitoring?
Usefully, yes. Monitoring tells you when a known condition happens: disk full, service down. Observability is the property of being able to investigate conditions nobody predicted, because the system emits enough telemetry (metrics, logs, traces) to answer new questions without shipping new code first. In practice an enterprise needs both, built as one programme.
Common question
Is this employee monitoring or facility surveillance?
No, and the confusion is common enough in this market to answer head-on. This practice observes systems: applications, infrastructure and networks. It has nothing to do with monitoring employees’ screens or buildings’ cameras; for camera-based industrial safety work, which is a different Interkey practice, see industrial safety monitoring.
Relatedindustrial safety monitoring
The decision
How the platform choice is actually made
In this order, deliberately: each constraint eliminates options before the next is considered, and the product conversation happens last. A team that starts from dashboard screenshots ends up justifying a choice instead of making one.
- Decide first
- 2. Estate shape
- The question
- How much is Kubernetes and cloud, how much is VMs, legacy and air-gapped?
- What it eliminates
- Tools that assume a cloud-native estate. The awkward half of a hybrid estate is where platforms differ most.
- Decide first
- 3. Cost model
- The question
- What is your real log volume and retention need, measured, not guessed?
- What it eliminates
- Platforms whose pricing model punishes your particular shape. The log bill is the decider more often than any feature.
- Decide first
- 4. Team
- The question
- Who will own the platform for years: an in-house team, a partner, or nobody?
- What it eliminates
- Self-hosted stacks, if the answer is nobody. A self-hosted platform without an owner is an outage with a delay on it.
- Decide first
- 5. Product
- The question
- Of what survives the four constraints, which fits best?
- What it eliminates
- Only now do demos, feature lists and vendor conversations earn their place.
The signals
What the four telemetry types actually answer
Observability is assembled from four kinds of data, and they are not interchangeable. Most estates over-collect one and under-collect another, which is why the bill and the blind spots usually arrive together.
- Signal
- Metrics
- The question it answers
- Is this healthy, and is the number moving? Numeric values sampled over time — request rate, error rate, latency, saturation.
- What it costs you
- Cheap to store and quick to query. The limit is that a metric tells you something changed, never which request or which customer.
- Signal
- Logs
- The question it answers
- What exactly happened in this one case? The event record, with the detail a metric discards.
- What it costs you
- The expensive signal, and the one that decides most platform bills. What drives the volume is worth measuring before it is committed to.
- Signal
- Traces
- The question it answers
- Where did the time go across services? One request followed end to end through every hop it made.
- What it costs you
- Requires instrumentation in the application, not just around it. This is where OpenTelemetry earns its place, because the instrumentation outlives the platform.
- Signal
- Events and changes
- The question it answers
- What did we do to it? Deployments, configuration changes, scaling actions, incidents.
- What it costs you
- Nearly free, and routinely skipped. Without it, every investigation starts by asking what changed and nobody can answer.
The engagement
What an engagement delivers, on any platform
The platform decides the tooling. It does not change the work, which is the same four deliverables whether the answer was SaaS or self-hosted.
01
Assessment
What runs, where it runs, which services carry the business, what the residency position is, and what the current monitoring actually catches. The output is a scoped plan, not a licence count.
02
Instrumentation
Agents, integrations and OpenTelemetry across the estate, including the half the quick-start guides skip: proxies, air-gapped segments, and systems that cannot take an agent.
03
Dashboards and alerting
Built for the teams that own the services, with alerts designed around consequence, so that what fires at 3am is worth being awake for.
04
Operation or handover
Either Interkey operates the platform on the Saudi working week, or your team takes it over with standards, documentation and training that survive the handover.
Day two
Who owns the platform after go-live
Every observability platform decays. Agents fall behind, tags drift, alert thresholds stop matching the system they watch, and log volume grows until somebody notices the invoice. None of that is a failure anyone is paged for, which is exactly why it accumulates.
There are three workable answers, and the choice belongs at design time because it changes what gets built. An in-house team that will own it wants the platform built the way they work and documented for handover. A team that will not own it needs the alert set kept deliberately small, because every alert is a standing commitment on somebody's night. And where the answer is genuinely nobody, a self-hosted stack is the wrong shape at any price — the operating cost does not disappear, it moves somewhere it will not be tracked.
Interkey delivers against any of the three, including building the platform and handing it over. What it will not do is leave the question unanswered at go-live, because that is the version that fails quietly.
Go deeper
The observability library
Implementation
How Interkey implements Datadog
The rollout method, phase by phase: assessment, instrumentation, alert design, and operation after go-live.
Technical guideObservability data residency in Saudi Arabia
Where telemetry physically lands on each deployment model, what stays in-Kingdom, and how to evidence it.
Buyer guideControlling Datadog log costs
What actually drives the bill, the retention pressure pulling the other way, and the levers that move the number.
Implementation guideKubernetes monitoring in Saudi Arabia
Cluster visibility as a rollout with a security review, a cost budget and an upgrade path, not an install command.
Buyer questionsWhat buyers ask before a Datadog rollout
Cost drivers, agent coverage, telemetry residency and support hours, answered before the contract rather than after it.
ComparisonDatadog alternatives: when to switch, and when not to
Written by a Datadog implementation team, which is exactly why the second half of the answer is worth reading.
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
What does observability consulting actually include?
The four deliverables above: an estate and residency assessment, instrumentation across applications, infrastructure and logs, dashboards and alert design the owning teams actually use, and either ongoing operation or a proper handover. What it does not include is buying licences and leaving.
Should a Saudi enterprise run SaaS observability or a self-hosted stack?
Answer residency first and the question mostly answers itself. If your data classifications permit telemetry to leave the Kingdom, with filtering and redaction designed in, a SaaS platform buys a small team enormous leverage. If they do not, a self-hosted stack on in-Kingdom infrastructure is the right route, priced at its true cost: someone must own it for years. The residency guide works through both.
Relatedresidency guide
Can existing OpenTelemetry instrumentation be reused?
Yes, and it should be: OTel instrumentation is an asset that outlives platform decisions. A rollout designs around it, using vendor-native agents only where they buy real capability, and writes down which is which.
How does this reduce MTTR in practice?
Not by dashboards alone. Time-to-recovery falls when the on-call engineer trusts the alert, can see the blast radius in one place, and can follow a trace to the failing dependency instead of guessing. That is alert design, service-level dashboards and tracing, in that order of impact, and it is why alert redesign is where engagements on existing deployments usually start.
What should we prepare before talking to anyone, Interkey included?
Three things: a rough inventory of what runs and where, the shortlist of services whose failure actually hurts, and your data residency position or the name of whoever owns it. With those, a first conversation produces a scoped plan instead of a brochure.
Next
Explore related solutions
Next step
Discuss your observability environment
Whether the platform is chosen, contested or already bought, the useful first message is the same: what runs where, and what broke last. The practice starts from there.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia