Operations | Monitoring | ITSM | DevOps | Cloud

The dashboards are red, the alerts are firing, and Slack has officially become a war room. Someone has asked, “Anyone else seeing this?” and 14 people have immediately responded with screenshots. Welcome to another day in distributed systems. The recent GitHub outage is a great reminder of how complicated modern applications have become. Services talk to services, infrastructure scales up and down, retries multiply traffic, and dependencies behave in ways nobody expected.

Private cloud and on-premises infrastructure are different. I know this. I used the terms interchangeably anyway because I was trying to compress a pattern into one sentence. That was sloppy, but the underlying pattern still matters. Banks run Kubernetes differently from most other organizations. Not because every bank makes the same choices, but because similar constraints can produce a similar pattern.

The most common reason to create an API key in CloudZero is to send data, such as AI telemetry or billing exports. Until now, that meant picking individual scopes from a list and hoping you chose the right ones. That works on day one. The problem is day ninety. Permissions on a key have always been a snapshot of the day you created it. A new AI telemetry endpoint ships in October, and a key created in August has no idea it exists.

Somewhere in your service is a branch that has never executed. Not a rare one, a never one. It handles a dependency being unavailable: it reads from a cache, it returns a stale value, it marks the response degraded so callers know not to trust it too far. It was written carefully. It was reviewed. Whether it works is an open question, because nothing in the test suite makes that dependency fail, and the dependency does not fail on request.

An engineering leader asked me a question a few weeks ago: could we read their business workflows out of API traffic instead of asking people to document them? I said it should be possible. Then I tried it. A few engineers know how the system really works. They know which calls make up a work order and which checks happen after a write. That stuff rarely makes it into the test plan. Usually it’s in somebody’s head. Sometimes it’s in several heads, with slightly different answers.

Monitor dependencies are now available through the StatusGator v3 API. The new endpoint lets you programmatically retrieve the relationships and dependencies associated with a monitor, giving your integrations and internal tools more context about the services each monitor relies on. Dependencies are already available in the StatusGator UI for Website, Ping, and Custom monitors, while StatusGator automatically identifies relationships for many Service monitors.

Summary: An API defines how software interacts with a service. MCP defines a standard way for AI applications to discover and invoke tools exposed by a service. They usually work together: an MCP server can sit in front of APIs you already run, turning low-level operations into capabilities an agent can find and use at runtime. Your API may already expose everything an AI agent needs. The harder problem is helping the agent figure out which operations matter for the task it has been given.

A metric says latency increased. A log says a request failed. A trace identifies the slow dependency. An APM agent points to the method. Manual instrumentation explains the business operation. Traffic capture shows the exact request and response that triggered it. Each layer answers a question the previous layer could not. Each also introduces a new cost, blind spot, and failure mode.

Engineering leaders have been claiming to “shift quality left” for years but production remains stubbornly stuck out of reach of software engineers. The realm of production remains mysterious with tools no one has access to and UIs that wouldn’t make sense to engineers anyway. I’ve noticed a small but growing trend of large enterprises hiring Reliability Engineers instead of Site Reliability Engineers. Dropping one word looks cosmetic but I think it points to a much bigger change.