The observability practice
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.
The gap
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.
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 and partners on is Datadog. The decision framework below is written to survive that disclosure, it eliminates by constraint before any product name appears, and where the constraints point away from a SaaS platform, Interkey says so in public.
Terminology, settled
Common question
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
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.
The decision
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 | The question | What it eliminates |
|---|---|---|
| 1. Residency | Where may telemetry physically land, per data classification? Logs especially. | Everything. If telemetry must stay in-Kingdom, SaaS platforms without an in-Kingdom control point are out, whatever their features. Worked through here. |
| 2. Estate shape | How much is Kubernetes and cloud, how much is VMs, legacy and air-gapped? | Tools that assume a cloud-native estate. The awkward half of a hybrid estate is where platforms differ most. |
| 3. Cost model | What is your real log volume and retention need, measured, not guessed? | Platforms whose pricing model punishes your particular shape. The log bill is the decider more often than any feature. |
| 4. Team | Who will own the platform for years: an in-house team, a partner, or nobody? | Self-hosted stacks, if the answer is nobody. A self-hosted platform without an owner is an outage with a delay on it. |
| 5. Product | Of what survives the four constraints, which fits best? | Only now do demos, feature lists and vendor conversations earn their place. |
The engagement
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.
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.
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.
Built for the teams that own the services, with alerts designed around consequence, so that what fires at 3am is worth being awake for.
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.
Go deeper
The rollout method, phase by phase: assessment, instrumentation, alert design, and operation after go-live.
Technical guideWhere telemetry physically lands on each deployment model, what stays in-Kingdom, and how to evidence it.
Buyer guideWhat actually drives the bill, the retention pressure pulling the other way, and the levers that move the number.
Implementation guideCluster visibility as a rollout with a security review, a cost budget and an upgrade path, not an install command.
ComparisonWritten by a Datadog partner, which is exactly why the honest half of the answer is worth reading.
Buyer questions
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
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.
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 honest route, priced with its true cost: someone must own it for years. The residency guide works through both.
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.
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.
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 step
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
Elsewhere