Operations | Monitoring | ITSM | DevOps | Cloud

We shipped a chaos feature that never caused any chaos. Our mock server has had a fault-injection effect for years with a straightforward job: withhold the response entirely and see whether the caller copes. Last week I audited it against the actual code path. It had never withheld anything. The handler returned early without writing a response. Go’s net/http then did what it is designed to do, which is synthesize a 200 OK and flush the recorded body.

A chart shows you that CPU jumped at 15:57. It doesn’t show you that a deploy went out at 15:56. Chart annotations let you pin a note to the exact moment on a chart, and it stays there for everyone in your Space, permanently, the next time anyone looks at that chart.

To deploy an application we haven't seen before, we need two things out of its repository. One is a Dockerfile that builds it. The other is a service definition saying what runs, which ports it listens on, which databases it needs, and what environment variables it expects. Customers arrive with a git URL, and we figure out the rest. We even do the tricky task of generating a Dockerfile if it doesn't already exist in the codebase. We've built a solution for this twice already.

Splitting one big pull request into five smaller ones doesn’t automatically make review faster. It just moves the complexity from the diff to your head, unless something keeps track of the order for you.

The compliance question isn't "are we using a private cloud?" Rather, it’s "does our private cloud actually do what compliance requires?" Private cloud has a reputation for solving compliance problems that it doesn't always deserve. The logic seems straightforward: keep data off shared public infrastructure, maintain more direct control, and satisfy the auditors.

You are mid-investigation, chasing a spike or pulling a number for finance, and you hit a term or a workflow you need to look up. You should not have to lose your place to find an answer. Guide lives in a fixed spot in the left sidebar, always one click away. It opens a panel on the right side that sits beside your page instead of covering it. Your chart, filters, and time range stay exactly where they were. Nothing gets rebuilt and you keep the thread of what you were investigating.

Every finance person I know lives in the same loop approaching the end of the month, quarter, or fiscal year. Leadership wants to know where the financials will land (most times before the close has occurred). CS wants customer margins. Someone on the People team needs each department’s AI spend for an OKR review, and they need it quickly to make business decisions. Each answer sits in a different tool or a different spreadsheet, and I bounce across all of them several times a day.

Hyperscale providers are nothing if not consistent in their temptation of enterprise IT buyers. They bombard leaders with a simple message: migrate to the public cloud, shut down data centres, and enjoy both financial savings and operational agility. However, as UK enterprises have scaled their digital footprints, a more nuanced reality has bitten. Public cloud costs have swollen.

Feasibility is a prioritization question that comes before strategy. The five-question check produces a "now, later, or fix blockers first", before anyone touches a target architecture. Strategy earns its place once feasibility returns "now." Feasibility comes before strategy. Before anyone designs a target architecture, builds a runbook, or commits to a multicloud operating model, the question is whether the migration is the right move now, and what would make it fail.