Operations | Monitoring | ITSM | DevOps | Cloud

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.

Scoped chaos rules are now in proxymock. A filter query picks the traffic, an effect perturbs it, and every response that gets touched is labelled so you can tell an injected failure from a real one for the rest of the run. Available in v2.5.892 and newer. The short version of why: kill a pod and you learn something real, but you do not learn what your service does when a dependency stays up and starts lying to it.

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.

Managing monitors has meant one of two things: the dashboard, or writing your own API calls. There is now a third. The official UptimeRobot CLI is live on npm, and it drives every monitor, incident, and status page in your account from the shell you already have open. It is free, open source under Apache 2.0, and works on every plan including the free one.