Fractal Sprint | Webinar: How to Build a Governed Developer Platform | Watch Now →

Fractal Cloud

Blog

Notes on the agentic platform, governance and sovereignty, plus stories from the customers and partners we work with.

All
Day 2 Operations
Governance
Multi-Cloud
Platform Automation
Platform Engineering
The metric CTOs never look at: the average age of infrastructure debt

The metric CTOs never look at: the average age of infrastructure debt

A CTO watches uptime, team velocity, and the monthly cloud bill. Those three are easy to watch: they update themselves, they have dashboards, and they compare month over month without anyone building anything.Now try to answer a different question from those same three dashboards. For each production environment, how long has it been since it last matched the definition it was built from? Uptime cannot tell you. Velocity measures the code your teams ship, not the infrastructure they stopped touching. The bill goes up when things are neglected, not down, so it does not even point in the right direction.That question has a measurable answer, and almost nobody measures it.

Day 2 Operations
Why Great Observability Still Wakes You Up at 3 AM

Why Great Observability Still Wakes You Up at 3 AM

Closing the Loop Between Observability and InfrastructureMost organizations have good observability. They know within seconds when something breaks. And then someone gets paged.Alerts fire into runbooks, runbooks require humans, and humans are a bottleneck. The industry spent a decade solving the seeing problem. The acting problem is still largely manual.According to ITIC 2024 analysis, every minute of downtime costs a data center an average of $9,000. Speed and precision of response are not an operational detail: they are the factor that determines the final cost.There are two reasons this persists: operational data is fragmented across tool silos, so no single system has the full picture; and organizations don't trust automation they can't explain. Both problems need the same fix: a layer that contextualizes events across the full system, reasons deterministically about what to do, and executes infrastructure changes with full traceability.

Day 2 Operations
Illustration of Fractal Cloud managing post-provisioning activities such as compliance, patching, and policy enforcement across cloud infrastructure

What happens after Provisioning? The hidden cost of maintenance.

Provisioning is just the beginningIn the lifecycle of cloud infrastructure, provisioning is often seen as the finish line. Once the environment is defined and deployed, the job feels done. The code has been reviewed, the resources are running, services are responding. From that point on, it seems like it’s just a matter of keeping things going.But in reality, that’s when the most critical part begins. That’s where the real cost of infrastructure starts to surface (the part you don’t see immediately), but that gradually becomes heavier with time. Environments that were supposed to be identical begin to behave differently. Security patches are applied in some places, missed in others. Configuration drifts start to appear. Coherence slowly fades, and with it, confidence in the system.If you've worked in production, you know this too well. Many incidents don’t happen during provisioning, but weeks or months later when something that was working just fine suddenly fails. The root cause isn’t always in the code. Often, it lies in what changed over time, unnoticed and unmanaged.

Day 2 Operations
Fractal Cloud architecture illustrating resilient and secure cloud infrastructure with global distribution

Disaster Recovery: Your RTO Is a Guess Until You Test It

In cloud engineering, there is a fundamental truth: systems fail. It's not a matter of "if," but "when." Provider Service Level Agreements (SLAs), with their "nines" (99.9%, 99.99%), are not a promise of infallible uptime; they are the contractual guarantee that failures, however rare, are an expected part of the service.The "Shared Responsibility" model is clear: the provider is responsible for the reliability of the infrastructure, while we are responsible for the reliability of our applications running on it.When a core service or an entire region goes offline, it's not a "betrayal." It's an expected operational event. The real question isn't why it happened, but how we respond.

Day 2 Operations