Arkos builds cloud infrastructure for compute-intensive platforms that operate at serious scale. Their systems span hundreds of interdependent services across multiple environments, and the teams running them are expected to move fast without making catastrophic mistakes. At that volume, even a few minutes of lost visibility during an incident translates directly into downtime, missed SLAs, and engineering hours spent firefighting instead of shipping.
The Problem
Arkos had built up a monitoring stack over several years the same way most infrastructure teams do: one tool at a time, each one solving the problem in front of them. By the time the team had grown to managing over 400 services in production, they were running five separate tools across observability, alerting, dependency tracking, health monitoring, and change logging. None of them shared a data model. None of them gave a complete picture on their own.
When something broke, the response process looked like this: an alert fires, an engineer gets paged, they open four or five dashboards, cross-reference what they are seeing, try to figure out what is upstream and what is downstream from the failing service, and start making calls based on whatever they happen to know from memory. The speed of that process depended almost entirely on who was on call and how well they knew the system. Newer engineers needed help navigating it. Even experienced engineers wasted time context-switching just to form an accurate picture of the blast radius.
The architecture was real, but the documentation of it was not. Diagrams went stale within weeks of being drawn. Service relationships existed primarily in the heads of the engineers who had built them. Bringing someone new up to speed on how the system actually behaved, under load, in production, took the better part of a month.
How Arkos Used STRAND
Arkos deployed STRAND across their full production environment and mapped their entire service graph from the start. The dependency visualization surfaced relationships that the team had never formally documented, including several critical upstream dependencies that had no active ownership and no health monitoring attached to them. The map became the source of truth the team had been missing.
The immediate operational change was in how the team responded to incidents. Instead of opening multiple dashboards and piecing together a picture manually, engineers opened STRAND and got a complete view of what was affected, what was connected to the failing service, and where the fault was most likely originating. The time between alert and accurate situational awareness dropped significantly from the first week of deployment.
STRAND's change impact analysis became a required step in Arkos's pre-deploy workflow. Before any change with meaningful blast radius, the team runs an analysis to see which downstream services will be touched. High-risk paths get flagged before anything ships to production. Several incidents that would have gone undetected until after deployment were caught at the analysis stage instead.
Over the following months, Arkos decommissioned the five monitoring tools they had been running in parallel. STRAND consolidated the dependency map, health visibility, change tracking, and impact analysis into a single workspace. The overhead of maintaining separate tooling and reconciling conflicting data across systems went away entirely.
The Results
Arkos reduced mean incident response time by 60 percent. That number reflects the gap between a team navigating a fragmented toolchain and a team working from a shared, live view of their system. The change was not about engineers moving faster. It was about engineers spending less time figuring out what they were looking at before they could actually fix anything.
Onboarding time for new infrastructure engineers dropped from several weeks to a few days. The STRAND dependency map gave new hires something concrete to study and orient themselves around, rather than relying on documentation that was already out of date or knowledge transfers that varied depending on who had time to give them. Engineers who joined after STRAND was in place described it as the first time they had felt genuinely confident about the system they were operating before their first month was up.
The reduction in tooling overhead was substantial as well. Five separate vendor contracts, five separate integrations to maintain, and five separate sources of incomplete truth were replaced by one workspace that stays current automatically as the system changes. The engineering time that was going into maintaining that stack is now going into the infrastructure itself.
Looking Ahead
Arkos continues to scale. New services get added to the dependency graph automatically, and the change impact workflow has become a default part of how the team thinks about deploying anything significant. The goal they are working toward is not just faster incident response. It is reducing the frequency of incidents that require a response in the first place, by catching risky changes before they reach production. STRAND gives them the visibility to do that at a scale where it was not previously possible.
"Before STRAND, how fast we responded to an incident depended on who was on call and how well they knew the system that week. Now it depends on the tooling. That is a fundamentally different standard of reliability." Head of Platform Engineering, Arkos