Pip: Blender Fox has been busy — lacing up running shoes, watching cloud infrastructure catch fire, and apparently doing both in the same week.
Mara: Today we're covering two distinct territories: a return to a running habit and what those early sessions actually look like, and a Google Cloud outage that took down a GKE cluster and a MongoDB node at the same time. Let's start with the running.
Returning to the Road
Pip: The central tension here is a familiar one — you used to run, then you stopped, and now the apps you relied on have either died or drifted into something unrecognizable. So how do you actually structure a return?
Mara: The post frames it plainly: "It's been a long time, but I'm going to try to get back into running. Most of my old apps have died or no longer serve the original purpose they had."
Pip: That's the infrastructure problem of fitness habits — the scaffolding you built last time doesn't survive a long gap. You come back and have to rebuild from scratch, tooling included.
Mara: The practical answer here is Runnah, a new app, approached with deliberate caution — trial first, then monthly, then annual only if the habit proves it'll stick. The app also surfaces strength workouts, which fits the situation: a barbell and dumbbell set already on hand.
Pip: Choosing a beginner plan when you're not a beginner is one of the smarter calls in fitness.
Mara: The post flags that directly — not new to running, but far enough out that a slow re-entry makes more sense than picking up where things left off. The first session reflects that: five minutes walking warm-up, three sets of three minutes running at conversational pace with two minutes walking between, then a five-minute cooldown.
Pip: The second run, covered in the follow-up Training post, adjusts the intervals — ninety seconds at conversational pace, ninety seconds walking, then a four-minute conversational pace block, two minutes walking, same warm-up and cooldown bookends.
Mara: And it landed well. The post puts it simply: "Today's run was nice. Comfortable, with some harder uphills in the middle." The structure is doing what it's supposed to — accumulating time on feet without blowing up the effort level.
Pip: Two runs in, a new app on trial, a plan that's working. The question now is just consistency.
Mara: Which is exactly where these plans either hold or don't. Speaking of things that don't hold — let's talk cloud outages.
When the Cloud Has an Off Day
Pip: Sometimes your infrastructure just decides it's done for the afternoon, and there's genuinely nothing you can do about it.
Mara: The post describes a GCP regional failure in London that took down part of a GKE cluster and degraded live services. A MongoDB Atlas node — running on GCP but outside the main account — also went down. Atlas's own message made the situation clear: "The Cloud Provider you've chosen is out of capacity for the selected database deployment configuration. We will continue to try and deploy on the chosen Cloud Provider."
Pip: So the recommended fix is to pick a different provider or region — except you can't action that mid-incident when the provider is the problem.
Mara: The saving detail is that the affected Mongo node was an analytics node, not serving live traffic. Most services were back up by the time the post was written, though GCP's own status page didn't flag any issues until around two hours after problems first appeared.
Pip: A slow return to running and a cloud region that needed a lie-down — not a bad week's worth of material.
Mara: The running story is still early. Next sessions will show whether the plan holds.
