Platform operation
A platform Interkey implemented, operated after go-live on the agreed scope. The most common shape, and the one where the transition is shortest because the runbooks were written during the build.
The operations practice
Managed services in Saudi Arabia
A platform is not finished at go-live; it is finished when someone is accountable for it every week after. This practice is that accountability, scoped to the platforms Interkey builds and understands, and written down before it starts.
In short
Interkey operates what Interkey implements
Interkey runs enterprise platforms for organisations in Saudi Arabia after they go live: the observability platform, the container platform, the data platform, the API layer, and the interfaces between them. Upgrades, capacity, incidents, changes and the monthly account of what happened, on a scope agreed in writing, by a team in Riyadh working in Arabic and English.
This is deliberately not a general IT outsourcing offer. Interkey does not take over a help desk, a user estate or a network it did not design, and it does not describe itself as a security operations provider. The service is bounded to platforms Interkey builds and understands, because operating a platform well depends on knowing why it was built the way it was.
The reason it exists as a practice is the failure mode every implementation page on this site names: the platform that was correct at go-live and neglected afterwards, until an upgrade nobody scheduled becomes an outage nobody planned. Most organisations can build a platform with help. Fewer can staff its operation for years, and the honest answer to that gap is a service rather than a hope.
Scope
What is in the service, and what stays yours
Scope is stated per platform, because “managed” means something different for a cluster and for a database. What the client keeps is as much part of the agreement as what Interkey takes.
| Platform | Interkey operates | You keep |
|---|---|---|
| Observability | Agent and platform upgrades, ingestion and cost control, alert hygiene, dashboards for the teams on call, and the monthly review of what fired and why | The decision about what matters: which services, which thresholds, who is paged. Interkey proposes; your service owners decide. |
| Containers and Kubernetes | Cluster upgrades with rehearsed rollback, capacity and node management, admission policy, registry and image hygiene, and platform-level incidents | The applications on the cluster and their releases. The platform is operated; the workloads are yours unless a separate agreement says otherwise. |
| Data platform | Version and patch cadence, backup verification by actual restore, capacity, replication health and platform-level performance | Schema, data and the application that writes it. Change delivery is the database DevOps practice, taken on separately if wanted. |
| API layer | Gateway upgrades, policy configuration changes through a change process, consumer onboarding, per-consumer monitoring and the deprecation calendar | The policy itself and the services behind the gateway. Who may call what is your decision, enforced by Interkey. |
| Interfaces | Monitoring for volume, failure and staleness, first response to interface incidents, and the inventory kept current as vendors change fields | The systems on either side and their vendors. Interkey owns the join, not the ends. |
The agreement
What a service agreement has to say before anything is operated
Managed services fail in the gap between what the client assumed and what the provider wrote down, and the gap is widest where the agreement is vaguest. So the agreement is written first, and it is specific: which platforms, which environments, which hours, which changes Interkey may make without asking and which need approval, how an incident is raised and by whom, what is reported monthly, and how the service ends and hands back.
Coverage hours and response targets are terms of each agreement, set against what the platform actually needs and what the organisation is prepared to pay for, which is why this page publishes none. The standard working pattern is the Riyadh team on the Saudi working week; anything beyond that is designed and priced for the platforms that genuinely need it, not applied by default to platforms that do not.
Transition
How a platform comes into service
Whether Interkey built the platform or is inheriting one it did not, the sequence is the same, and skipping the second step is how a provider discovers what a platform really does during its first incident.
-
Assess
The platform as it actually is: versions, configuration, drift from what was documented, the monitoring that exists, and the backlog of upgrades nobody scheduled. The output is a list of what has to be fixed before it can be operated responsibly.
-
Document and remediate
Runbooks written from the platform rather than from memory, the urgent items in the assessment fixed, and the monitoring brought to the standard the service needs. This step is priced separately because its size is not known until the assessment is done.
-
Shadow
Interkey watches and responds alongside the current operator for a defined period, so the first incident handled alone is not the first incident seen.
-
Take over
The agreed scope moves to Interkey on a stated date, with the change process, incident route and reporting live from that day.
-
Review and adjust
Monthly reporting of what happened, quarterly review of whether the scope still fits, and a standing answer to the question every buyer should ask: what would we need to take this back in-house, and is that documented.
Shapes
How the service is usually shaped
Three shapes, and a fourth that is really a project.
Inherited platform
A platform built by someone else, on a technology Interkey implements. Assessment and remediation come first and are priced first; the service starts when the platform is in a state that can be operated responsibly.
Backing your team
Your engineers operate day to day; Interkey holds the escalation, the upgrade planning and the specialist work a small team cannot keep current. Often the right shape for organisations that want to keep the capability but cannot staff its depth.
Assessment only
The first step bought alone: what state is this platform actually in, what needs fixing, and what would it take to operate it. Useful whether or not Interkey operates it afterwards.
The Saudi layer
What is specific to this market
Two things change the shape of a managed service here.
The operator’s tooling is subject to the same residency rules as the platform. Remote access, monitoring data, ticket contents and runbooks all describe or touch the estate, and where they are held is a classification question. A service designed for this market keeps its operating tooling in-Kingdom where the platform’s data is, and says so in the agreement rather than in a footnote.
The working week is Sunday to Thursday, and the team is in Riyadh. An organisation whose change windows, month-end and escalation contacts run on the Saudi calendar is operated by a team on the same calendar, in Arabic and English, in the same time zone. This sounds obvious and is the single most common complaint about services delivered from elsewhere.
The operations team is the same engineering practice that implements the platforms, which is the reason the service is bounded to them: an operator who did not build a platform learns it during incidents, and an operator who did already knows where it will break.
What good looks like
How to tell whether a platform is actually being operated
Apply these to any provider, including this one. Each is either true or not, and each can be checked without asking the provider:
- Every platform in scope is on a version its vendor still supports, and the next upgrade has a date
- The last backup restore was rehearsed, not assumed, and the date and outcome are recorded
- Every alert that fired last month reached a named person, and the ones that were noise have been removed
- Every change made to the platform is in a record that says what, when, by whom and why
- The monthly report was read by someone on your side, and it changed at least one decision this quarter
- The runbooks describe the platform as it is today, and your own engineer could follow them
- You know what it would take to bring the service back in-house, because the agreement says so
Questions
Questions buyers actually ask
Common question
Will you operate a platform you did not build?
If it is a technology Interkey implements, yes, after an assessment and whatever remediation it finds. The assessment is not a formality: platforms built by someone else frequently arrive with upgrades years overdue, no tested restore and monitoring that alerts nobody, and taking them into service in that state would be taking on an outage. The remediation is priced separately because its size is unknown until the assessment is done.
Common question
What response times do you commit to?
The ones in your agreement, set against what the platform needs and what you are prepared to fund. No default figure is published here because a response target is a term, not a fact about Interkey, and a number on a web page would be either a commitment nobody authorised or a marketing line nobody will honour. The agreement states it; the monthly report shows whether it was met.
Common question
Does this include security operations?
No. Interkey keeps its platforms patched, configured to the standards the implementation set, and monitored for platform-level events, and it works with whoever holds your security operations. It does not describe itself as a security operations provider and does not offer threat monitoring, incident response for security events or compliance assurance as a service. If a provider bundles those into a platform service, ask who exactly is on the other end.
Common question
How do we get out?
On the notice in the agreement, with a handover that includes current runbooks, the change and incident record, and the credentials and configuration in a form your own team or another provider can use. A managed service that is hard to leave is a dependency, not a service, and the handover clause is worth reading before the pricing.
Common question
Is this cheaper than hiring?
Sometimes, and that is not the main argument. The case for the service is depth and continuity: a platform needs someone who has seen its failure modes before, and needs them on the week the one engineer who knew it is on leave. A team that can staff that depth in-house should; the honest shape for one that cannot is often “backing your team” above rather than full operation.
From the insights library
The platforms this operates
Technology
Docker and Kubernetes implementation and operations
The container platform, including the managed-versus-self-managed decision that decides how much there is to operate.
TechnologyDatadog implementation and operations
The observability platform: what operating it after go-live involves, and why alert hygiene is most of it.
TechnologyCouchbase implementation in Saudi Arabia
The data platform side: versions, restores and capacity, operated as a platform rather than left to the application team.
Explore related solutions
Next step
Start with the platform you worry about
Name the platform, who operates it today, and when it was last upgraded. That last answer is usually the whole conversation.
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