01
Instrumentation
Across applications, infrastructure and logs, starting from the handful of signals that show whether the service is genuinely healthy from the outside.
Technology partners
Interkey implements Datadog observability in Saudi Arabia
Interkey is a Datadog partner in KSA. It implements observability for Saudi organisations: deciding what to watch, instrumenting for it, designing alerting that reflects how teams actually work, and operating the platform after go-live.
The failure mode
What Interkey delivers with Datadog
Observability tooling is easy to buy and easy to waste. The recognisable failure is a deployment where agents are installed everywhere, hundreds of dashboards exist, alerts fire constantly, and when something actually breaks the team still finds out from a user. The tool was not the problem; nobody decided what it should be watching.
Interkey’s work here starts from that decision. It means establishing what matters for a given system: the handful of signals that indicate whether the service is genuinely healthy from the outside, and instrumenting for those first, rather than collecting everything and hoping the important thing is in there somewhere.
That is also why this page says more about method than about product features. Datadog’s own site documents the platform better than any partner can. What it cannot document is how a rollout should run on a Saudi enterprise estate, half of which is in a local data centre and none of which can go down while the agents arrive. That part is Interkey’s.
The shape of it
How telemetry becomes an answer
Every observability programme, whatever the tooling, is this pipeline. The value is decided at the top, where instrumentation choices determine what can ever be seen, and at the bottom, where alert design determines whether anyone acts.
-
Applications and infrastructure
Kubernetes workloads, VMs, databases, network equipment, the legacy estate
-
Telemetry
Metrics Logs Traces -
Collection
The Datadog Agent and OpenTelemetry, through whatever network path your security model allows
-
Datadog
Dashboards, monitors, APM, log management
-
Engineering response
The only stage that changes an outcome: someone sees it, trusts it, and acts
Interkey’s implementation work concentrates on the first and last stages: deciding what to collect, and designing the dashboards and alerts that turn collection into response. The platform handles the middle.
The work
Instrumentation, dashboards, alerting, operation
An implementation is four kinds of work, and the order matters: instrument what proves service health first, then build the views and alerts people will actually trust.
02
Dashboards
Built for the people who will actually look at them, which usually means fewer and more specific.
03
Alerting
Designed around consequence rather than threshold, so that an alert firing at 3am means someone genuinely needs to be awake.
04
Operation
Agent versions, tagging discipline, cost review and alert tuning after go-live, because an unowned observability platform decays in months.
On alert fatigue.
Alert fatigue is the main reason observability platforms end up ignored, and it is a
design problem rather than a tooling one.
Delivery method
How a rollout actually runs
Phases rather than week numbers, deliberately: the honest duration depends on the size of the estate, the state of the deployment pipeline and how much of the work your own team takes on. What does not vary is the order.
-
Phase 01
Assess the estate and decide what matters
Inventory what runs, where it runs, and which services carry the business. Settle the data residency question before any agent ships a byte: what may be collected, what must be filtered or redacted, and where it is allowed to land. The output is a scoped instrumentation plan, not a licence count.
-
Phase 02
Instrument the systems that carry the business
Agents and integrations across the first tranche of hosts, clusters and applications; OpenTelemetry where instrumentation should stay portable; the network path (proxies, firewall rules, private registries for disconnected clusters) agreed with the security team rather than worked around.
-
Phase 03
Build the dashboards and design the alerts
Service-level dashboards for the teams that own the services, an alert set designed around consequence, and escalation wired into however the organisation actually responds: on-call rotas, ticketing, messaging.
-
Phase 04
Operate, tune and control cost
The period that decides whether the platform survives. Alert tuning against real incident history, log pipelines reviewed so the bill tracks value, tagging and agent-version governance, and a handover that leaves your team able to run it, with Interkey staying involved as much or as little as you want.
The Saudi question
Hybrid estates, and where telemetry lands
Most Saudi enterprise estates are hybrid: long-lived systems in a local data centre running alongside cloud and Kubernetes workloads. Datadog handles that mix well, and it is where an implementation partner earns its keep, because the awkward half of a hybrid estate is precisely the half the quick-start guides skip.
The residency question deserves the same early attention. Datadog is a SaaS platform operated from a set of published regions, and as of August 2026 none of those regions is in the Middle East. That is not automatically a blocker: it means the decision about which telemetry leaves the Kingdom, which is filtered or redacted before it goes, and which stays behind entirely has to be made deliberately, at design time. Interkey has written that reasoning up in full in its data residency guide, and where the answer rules a SaaS platform out, it will say so: that case is on the when Datadog is not the right platform page.
The bill
Log volume is where Datadog costs get decided
Per-host pricing is predictable. Ingested log volume is not, and it is where Datadog bills escalate, usually because a handful of chatty systems are shipping debug-level noise nobody reads. The discipline that keeps the bill proportionate is unglamorous: decide which logs need to be searchable, which only need to exist, and which should never leave your own infrastructure, then build the pipelines to enforce that.
Interkey treats cost design as part of implementation rather than a rescue project later. The full reasoning, including how Saudi retention expectations pull against the standard cost advice, is in the log cost guide.
Quick answers
The two questions every log conversation starts with
Common question
What determines Datadog log cost?
Mostly what you ingest and what you index. Ingestion is priced per volume; indexing, which is what makes logs searchable, is priced separately and is the larger lever. An estate that indexes everything pays for search on logs nobody will ever query. Exclusion filters, sampling and archiving exist precisely so that the default is not “index it all”.
Common question
Do all logs need to stay indexed?
No, and on most estates the majority should not be. The workable split is: a small indexed set for live investigation, a larger ingested-and-archived set that can be rehydrated when an incident or audit needs it, and a set that stays inside your own infrastructure entirely. Where the line sits depends on your retention obligations, which is a compliance conversation as much as a cost one.
Portability
The OpenTelemetry stance
Instrument portably where it is cheap; use the vendor’s agent where it earns its keep
Enterprises increasingly instrument with OpenTelemetry so that the instrumentation outlives any single vendor decision. Datadog ingests OpenTelemetry data, and existing OTel instrumentation is an asset in a rollout, not an obstacle: it changes the collection design rather than invalidating it.
Interkey’s advice is unexciting and consistent: instrument portably where the cost is low, use the vendor’s native agent where it genuinely buys capability, and write down which is which, so that a future platform decision is an engineering decision rather than an excavation. A partner whose answer to every question is “more of the vendor” is selling licences, not observability.
Day two
Who runs it after go-live
The quiet failure of observability projects is ownership. The integrator leaves, the dashboards age, agent versions drift, new services ship uninstrumented, and eighteen months later the platform is an expensive archive. Somebody has to own alert quality, cost review and instrumentation standards as ongoing work.
Interkey does that work on the Saudi working week, Sunday to Thursday from Riyadh, in Arabic and English, either operating the platform outright or backing the in-house team that does. The same engineers who built the rollout stay reachable, which matters at 3am in a way no support portal does.
In practice
The practice behind it
Not a logo on this page
Interkey and Datadog ran a joint Observability Day in Riyadh in November 2025, and the implementation work sits alongside Interkey’s container and Kubernetes practice and its mission-critical solutions work: because the systems worth instrumenting properly are usually the ones that cannot go down, and because container platforms are the most common trigger for the whole conversation.
Sectors
Industries and connected services
This work appears with telecommunications operators, government and semi-government services, energy and industrial operations, and e-commerce and logistics businesses, organisations where a service being degraded rather than down still has a real cost, and where finding that out quickly is the point.
It connects to Interkey’s DevOps and CI/CD capability, since instrumentation belongs in the deployment pipeline rather than being added afterwards, and to its software engineering practice, because meaningful application-level observability requires changing the application.
Telecom operators
Government services
Energy and industrial
E-commerce and logistics
From the insights library
Continue exploring observability
FAQ
Datadog: every question a buyer asks
Where your data lives, implementation and cost, and operating the platform after go-live, in one place.
Technical guideObservability data residency in Saudi Arabia
Where telemetry physically lands on each deployment model, what stays in-Kingdom, and how to evidence it in an audit.
Buyer guideControlling Datadog log costs
What actually drives the bill, the retention pressure that pulls the other way, and the levers that move the number.
Implementation guideKubernetes monitoring in Saudi Arabia
What breaks without cluster visibility, and how observability is designed for sovereign and on-premise clusters.
Datadog partner in KSA
As named in Datadog’s own partner overview
Riyadh engineering, Sunday to Thursday
Arabic and English, in the network’s own time zone
Observability Day, Riyadh 2025
A joint Datadog and Interkey event
Operating in Saudi enterprise IT since 1999
CR 1010156897
Next step
Discuss your observability environment
Tell us roughly what runs where — cloud, on-premise, clusters — and whether residency is a live question, and the first reply comes from an engineer who has done this here.
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
Elsewhere