Rendr builds and manages cloud infrastructure for engineering teams running production workloads at scale. Their platform handles provisioning, deployment pipelines, and runtime environments across distributed systems. As their customer base grew and the complexity of their own internal infrastructure followed, the gap between how fast they were building and how well they could observe what they had built started to widen.
The Problem
Rendr's build pipeline had grown into one of the most critical pieces of their internal infrastructure. Dozens of services depended on it, and any degradation in pipeline performance had downstream effects that were felt across the organization quickly. The problem was not that they lacked tooling to monitor it. The problem was that the tooling they had could tell them something was wrong but could not tell them where in the dependency chain the slowdown was originating or how far it would propagate before it was contained.
When build latency started creeping up, engineers would pull data from several different sources and attempt to triangulate the cause manually. The process was slow and inconsistent. Different engineers would approach it differently, arrive at different hypotheses, and spend time ruling things out that a clearer picture of the system would have eliminated immediately. By the time a root cause was identified, the cost in engineering time was already significant.
The underlying issue was that Rendr's observability tooling had no model of how their services related to each other. Metrics existed in isolation. There was no way to look at a performance problem in one part of the system and immediately understand which upstream dependencies were contributing to it or which downstream consumers were being affected by it.
How Rendr Used Strand
Rendr deployed Strand initially to address the build latency problem specifically. Within the first week, the dependency graph surfaced several upstream service relationships that engineers had not fully mapped, including two connections that were contributing to latency in ways that had not been visible in any of their existing tooling.
Once those relationships were visible, the diagnostic process changed entirely. Engineers responding to performance issues could open Strand, see the full dependency topology of the affected service, and identify candidate causes within minutes rather than working through a manual process of elimination across disconnected data sources. Impact analysis became a standard part of the workflow before any change to a service with significant downstream dependencies.
As confidence in the dependency map grew, Rendr extended their use of Strand beyond incident response and into their build process more broadly. Change impact analysis was integrated into pre-deployment review for any service touching the pipeline, which gave the team a consistent way to evaluate the blast radius of a change before it reached production.
The Results
Build latency dropped 40 percent in the two quarters following Strand deployment. The reduction came primarily from two sources: the identification of upstream dependencies that had been contributing to slowdowns without being visible, and the change in how engineers approached performance problems once they had a shared, accurate model of the system to work from.
Root cause identification, which had previously required pulling data from multiple disconnected tools and working through the system manually, became a faster and more consistent process. Engineers who joined after deployment reported that the dependency map made it significantly easier to get up to speed on how the system behaved under load.
The pre-deployment impact analysis workflow reduced the frequency of changes that produced unintended downstream effects. The build pipeline, which had been a source of recurring latency problems, stabilized as a result of both better visibility into its dependencies and more disciplined change management around services that fed into it.
Looking Ahead
Rendr continues to expand its infrastructure platform. As new services are added, they surface in Strand's dependency graph automatically, and the impact analysis workflow scales with the system. The engineering team's focus has shifted from managing the consequences of poorly scoped changes to using dependency visibility as a tool for making better decisions before changes are deployed.
"We knew build latency was a problem. What we did not know was how many upstream relationships were contributing to it. Strand made those connections visible in a way nothing else had, and from there the path to fixing it became straightforward." Brett Wilder, Infrastructure Lead, Rendr