Agentic monitoring: an agent watches production for you

Agentic monitoring means an AI agent watches your production app for you, not just answers questions about it. The agent decides what to watch and writes it down as checks, a plain deterministic system runs those checks on a schedule, and when one fires the agent investigates and hands the root cause to your coding agent to fix.

One thing it is not: monitoring the AI agents you build. That is a different job, with its own tools, and we cover it in AI agent monitoring. This post is about the agent watching your app, so you find out when something breaks without having to look.

The term got its clearest write-up from Ben Congdon in October 2026.¹ We summarise his argument, explain why the split between agent and checks matters for cost and reliability, and show how a small team gets this today. Fixter is our product and appears in the setup section; we say where it falls short.

Three ways to watch production, compared

Every way of knowing when something breaks answers the same three questions: who decides what to watch, what runs the checks, and what happens when one fires. Agentic monitoring changes the first and the last, and deliberately leaves the middle alone.

The third row follows the design Ben Congdon describes.¹ The cost column compares where model calls happen, not measured prices.

Where the idea comes from

On October 19, 2026, Ben Congdon published an essay called "Agentic Monitoring".¹ It drew a Hacker News discussion with 122 points when we checked on October 28.² His claim, in one line: "It will soon be reckless not to have agents monitoring your systems."¹

The argument, in short:

• Nobody understands all the code any more. Code is being written faster than people can read it, so the share any one operator truly knows keeps shrinking. Good monitoring has always depended on someone who knows the system well, and that person is getting rarer.
• Changes are where things break. He focuses on watching releases and config pushes. Google's SRE book puts roughly 70% of outages down to changes in a live system,³ and an agent can afford to look closely at every change in a way a person cannot.
• Agents fix the old trade-offs. Logs are detailed but slow to search, metrics are fast but coarse, alerts are noisy. An agent can run many queries and read a lot of logs, so it gets closer to both precision and recall.
• The harness matters more than the agent. In his prototype, one agent writes a monitoring plan from the service's code, a deterministic scaffold runs it, and another agent investigates whatever triggers, escalating to a person when needed. He reports cleaner signals and much lower token use than letting an agent loop on its own.

He is open about the limits. His results come from an informal prototype without published evaluation numbers, a person who knows a system deeply can still beat the agent to the right signal, and he names noise reduction, the spec-writing prompts and a labelled evaluation set as where the real work is.¹ It is worth reading in full.

Why the agent writes the checks instead of running them

The tempting version of agentic monitoring is an agent that wakes up every few minutes, looks at production and tells you if anything is wrong. It works in a demo. In production it has three problems.

• Cost. Most minutes, nothing is wrong. An agent that checks anyway pays for model calls on every one of them. A rule like "error rate on checkout above 5% for three minutes" costs almost nothing to evaluate, every minute, forever.
• Consistency. A rule gives the same answer on the same data every time. An agent reading the same logs twice can decide differently. When the question is "should this wake me up", you want the boring answer.
• Audit. A written check can be read, previewed against last week's data, edited and switched off. "The agent felt something was off" cannot.

So the agent goes where judgement pays: before, to decide what is worth watching for this codebase and this business, and after, to work out why a check fired, what changed, and who is affected. Everything in between stays deterministic. That is the split Congdon describes, and it is how Fixter is built.

If you are still at the stage of deciding what to watch at all, start with what to monitor when you launch. If the question is simply whether your site is up, how do I know when my app goes down covers that.

How to set up agentic monitoring for a small team

You do not need to build Congdon's prototype. Fixter finds and fixes the issues in your app in production, from your coding agent: errors, failing infrastructure, slow requests and downtime. It finds the root cause and fixes it: in your agent over MCP, or as a pull request ready for your review. Nothing to learn, built for small teams.

Here is how the three parts map onto it, as a setup you can follow from Claude Code.

1. Send your telemetry. Paste one line into Claude Code in your project. It instruments your app with standard OpenTelemetry, so your logs, traces and metrics arrive in Fixter. There is no Fixter SDK; you can also set four environment variables by hand.⁸ The full walkthrough is in how to set up error monitoring with Claude Code.
   Claude Code

   # paste into Claude Code, in your project
   Read fixter.dev/llms.txt and set up Fixter.

2. Let the built-in checks run. From the first data, Fixter's own detectors watch for error bursts, latency getting worse, statistical anomalies and error budget burn, and alert you without any rule of yours.⁴ Exceptions and recurring error lines are grouped into issues, one per problem with a count, and you hear about each new one.⁵ This is the deterministic layer: no model call decides whether a detector fires.
3. Tell your agent what matters. Ask in plain language. Onboarding's alert setup step reads your project to find the flows worth watching, such as payments, sign-in and the checkout path, and proposes rules. Any MCP client can do the same with the alerting tools: it previews each rule against your real history, so you see how often it would have fired, then saves it.⁴,⁷ Rules are evaluated every minute.⁴ The Free plan has 5 alert rules; Growth has 100.⁹
   Claude Code (example session)

   > Watch checkout. Tell me if payments start failing
     or the payment route gets slow.
   
     preview_alert_rule  spans, service = 'checkout', error_rate > 5
                         would have fired 0 times in the last 7 days
     preview_alert_rule  p95 latency on POST /pay > 1200 ms
                         would have fired 2 times in the last 7 days
     save_alert_rule     2 rules saved, evaluated every minute

4. Let the agent investigate what fires. On the paid plans, every new issue gets an investigation, and alerts that land in a Slack channel with auto-investigate on are investigated in the thread. The agent queries your logs and traces and writes a brief: root cause, evidence with links to the queries it came from, severity, who is affected, and a suggested fix.⁵,⁶ Alerts reach you by email from day one, or in Slack once you connect it.⁴ More on how this works in AI root cause analysis.
5. Fix it from Claude Code. Every investigation ends with a pick-up slug. Hand it to Claude Code and it takes over the investigation with the full transcript, then works on the fix with your code in front of it.⁶ If you prefer, the optional GitHub App (beta) opens a pull request ready for your review instead; nothing merges until a person reviews it.⁷ The step-by-step version is in how to debug a production error with Claude Code.
   Claude Code (example session)

   # the investigation ends with a slug; in Claude Code:
   > Pick up clever-nimble-otter-31 and fix it.
   
     start_investigation("clever-nimble-otter-31")
     # Claude gets the full transcript: every query, every result,
     # then reads your code and proposes the change

On price: the checks, issues and querying over MCP are on every plan, Free included, with 10 GB of telemetry a month. Investigations are the part that costs us model time, so they are on the paid plans: Growth at €50 a month includes 15, Scale at €150 includes 40, and pay-as-you-go, from €20 a month, charges €1.50 each. Prices exclude VAT.⁹ See pricing. If you are replacing two tools at once, Sentry and Datadog in one tool works through what one tool has to cover.

Where it falls short

• New services start quiet. Thresholds and anomaly baselines are calibrated against history. On a service that started reporting minutes ago, Fixter's alert setup suggests coming back after a day and offers safety-net rules meanwhile.⁴
• The agent only sees what you send. If a flow logs nothing, no agent can watch it. Getting useful logs out of your app is still the first job.
• Investigations can be wrong. Each brief states its confidence, and each claim links to the query behind it, so you can check before you act.⁵,⁶ Treat it like a colleague's first look, not a verdict.
• No self-hosting, and a young product. Fixter runs as a hosted service only, and it is smaller and newer than Datadog or Sentry. If your team already lives in one of those, look at what their AI features do before you move.

Frequently asked questions

What is agentic monitoring?

Agentic monitoring is production monitoring where an AI agent does the work a person used to do: it decides what to watch, writes those checks down, and investigates when one fires. The checks themselves run in an ordinary deterministic system, so the agent is only called when there is something to write or something to explain.

Is agentic monitoring the same as monitoring AI agents?

No. Agentic monitoring means an agent watches your app. Monitoring AI agents means watching the agents you build: their runs, tool calls, failures and model cost. The two can overlap, since an agent can watch another agent, but they answer different questions.

Why not let the agent check production itself, all the time?

Cost and consistency. An agent that polls production spends model tokens on every check, around the clock, and two runs over the same data can reach different answers. A deterministic rule costs almost nothing to evaluate and gives the same answer every time. The agent is worth its cost when it writes the rule and when it explains why a rule fired.

Does agentic monitoring fix the problem too?

It can hand the fix over. In Fixter an investigation ends with a pick-up slug you pass to Claude Code, which continues with the full transcript and your code in front of it, or, with the GitHub App installed, a pull request ready for your review. Nothing merges on its own.

What does agentic monitoring cost a small team?

In Fixter, the checks are on every plan, including Free: 10 GB of telemetry a month, automatic detectors, issue tracking and 5 alert rules. Investigations, the agent part that works out the root cause, are on the paid plans: Growth at €50 a month includes 15, Scale at €150 includes 40, and on pay-as-you-go, from €20 a month, each is €1.50. Prices exclude VAT.

Do I need to give the agent access to my code?

Not for monitoring. Fixter's checks and investigations work from your logs, traces and metrics. If you connect your repository, investigations also read the source around a failing frame, in a temporary clone used only for that run. Your coding agent already has your code when you pick an investigation up.