Monitor service health

When you'd do this

• Your morning check: is each service you own up, and are its error rate, latency and throughput where they should be?
• Someone says "it feels slow since yesterday" and you want to compare now with the same time last week in every tool, not just the one you have open.
• You are going on call and want to know what is firing, what is silenced and whether any alert rule is failing to evaluate.
• A dashboard panel looks wrong and you want to see the query behind it before you trust it.
• You are reviewing monitoring coverage: which services have no metrics, no alerts or no error tracking at all.
• A release has gone out and you want release health and the current SLO status before you call it done.

Debugging one specific error belongs on Debug a production error, and running an active incident belongs on From incident to fix. This page is the steady-state work: knowing what healthy looks like and noticing when it stops.

Before you start

• Vörr is connected to Claude, ChatGPT or another MCP assistant, and you have granted it access for your own user. ChatGPT needs a paid plan with Developer mode turned on.
• An administrator has connected the observability tools you rely on, for example Prometheus or another compatible source, Grafana, Loki, Datadog, New Relic, Dynatrace, Sentry or Alertmanager. CloudWatch comes through the AWS connection. Vörr supports more than 30 tools across metrics, logs, traces, errors, alerts and CI/CD.
• Connections use read-only credentials, such as a Grafana Viewer service-account token.
• Your important services are mapped in the service map, so that one service's different names in each tool are tied together. Only administrators can edit the service map.
• The services are mapped to workspaces and environments. Answers draw on the organisation's connected sources, and workspaces label what comes back.
• For the code side, CodeZero is installed in VS Code with your organisation's repositories indexed, including the ones that hold alert rules, dashboards-as-code and Helm or Terraform config.

If any of this isn't set up yet, start here:

• Connect observability and CI tools
• Add Vörr to Claude or ChatGPT
• Roles and permissions
• Install and connect CodeZero

How a health answer is put together

Every operation below follows the same three rules, and it helps to know them before reading the results.

The name is resolved first

Vörr looks up the service in the service map, then in confirmed aliases, then in catalogue names, and only then tries the name you typed. Each result says how the service was matched: explicit, identity, exact, name or unmapped.

Each source answers separately

When several connected tools can answer, each one is queried and reported on its own, with its source and environment. Values are never averaged, and one source failing does not erase the others.

Gaps are reported, not filled

If no connected tool can answer a question, the answer says "no connector" rather than guessing. Coverage questions tell you which sources can answer what and why an answer might be wrong.

Run a daily health check of a service

1. In Claude or ChatGPT, ask Vörr for the service's health over a window you choose: up or down, error rate, p95 latency (plus p50 and p99 where the source reports them), and throughput.
2. Vörr resolves the service name in each connected tool and queries every source that can answer.
3. The assistant reads the per-source results and summarises them, keeping each figure attached to the tool it came from.
4. Check the match quality on each line. A name match is worth confirming before you act on it.

A good result has one row per source rather than one blended number, names the environment, and lists any source that could not answer. If the latency figures from two tools differ, that difference is information, not noise. The next operation covers it.

Compare windows and spot source disagreement

1. Ask Vörr to compare a current window with a reference window, for example the last hour against the same hour seven days ago.
2. Vörr returns the delta for each metric in each source and flags where the sources disagree about the direction or size of the change.
3. If the sources disagree, ask why: different counting of retries, different scopes such as one tool covering only one region, or a different service matched.

Verify a disagreement by checking the matched names first. Two tools that matched two different services will always disagree. If the names match, open the dashboard query behind each figure (see Read dashboards below) to see what is being counted.

Check CloudWatch metrics against the baseline

1. For services on AWS, ask Vörr whether the service's CloudWatch metrics are normal.
2. Vörr checks the current values against a 14-day baseline and labels each one normal, elevated or unprecedented, or unknown where there is no baseline yet.
3. Treat "unprecedented" as a prompt to look closer, not as an incident. A planned load test or a new feature can produce it.

A good result names the metric, the current value and the verdict. If something is elevated across a service and its dependencies at once, ask for recent deploys next. Investigate deployments and CI failures covers that path.

Check infrastructure health and Kubernetes top consumers

1. Ask Vörr for the infrastructure behind a service: CPU, memory, restarts and pods ready, from Grafana-connected Kubernetes metrics.
2. For clusters, ask for the top CPU or memory consumers by pod, namespace, deployment or node.
3. Compare the consumers with the service's own health. A pod near its memory limit with rising restarts often explains latency before errors appear.

To verify, check that the namespace and deployment names in the answer are the ones you expect. If a deployment you know exists does not appear, ask whether the source covers that cluster before reading it as healthy.

Check SLO status and release health

1. Ask Vörr for the current status of the SLOs defined for a service in the connected tools, with remaining budget where the source reports it (for example Dynatrace).
2. After a release, ask for release health where the connected tool reports it, alongside error rate and latency for the same window.
3. Read the SLO status alongside the release. An SLO that is still within target but trending worse since the release is a reason to watch, or to roll back.

If no connected tool defines SLOs for the service, the answer should say so. That is a coverage finding worth recording, not a reason to invent a target.

Review firing alerts, rule history and thresholds

1. Ask Vörr which alerts are firing for a service or across a workspace.
2. For an alert you are unsure about, ask for its rule: the threshold, the evaluation history and when it last changed state.
3. Compare the threshold with the current values from the health check. An alert that has never fired with a threshold far above normal traffic is not protecting much.

Check routing, contact points and silences

1. For Grafana alerting, ask Vörr where an alert routes: the routing policy and contact points it reaches.
2. Ask which silences are active, what they match and when they expire.
3. Ask whether any rule is failing to evaluate. A broken rule is silent in the same way a healthy service is.

Read dashboards and run a panel

1. Ask Vörr for a Grafana dashboard's panels and the query behind each one.
2. Read the queries. Look for filters on the wrong label, a hard-coded environment or a rate window that hides spikes.
3. Ask Vörr to run one panel for a window you choose, so you see its data without opening the dashboard.

Run a raw PromQL or LogQL query

1. When the question is more specific than the built-in health checks, ask Vörr to run a raw PromQL query against a named Prometheus-compatible source, or a LogQL query through a Grafana Loki datasource.
2. Say which source, because the same query can return different results in two Prometheus-compatible backends.
3. Ask the assistant to show the query it ran alongside the result, so you can reuse or correct it.

Log lines come back redacted. Raw queries are read-only, like every other Vörr operation from the assistant.

Check coverage: who can answer what, and what nobody watches

1. Ask Vörr which connected sources can answer which kinds of question for a service: metrics, logs, traces, errors, alerts and deploys.
2. Ask which services nobody watches, meaning known services with no source reporting on them.
3. Ask for the reasons an answer about a service could be wrong right now, such as active silences, failing rules or an unconnected source.

This is the operation that turns "nothing found" into one of three answers: verified quiet, not connected, or not asked. Run it before you report a service as healthy to anyone else.

Resolve names: list entities, the service map and match quality

1. Ask Vörr to list the real service, job and project names in a connected tool, rather than guessing them.
2. Ask how a service is matched in each tool, and whether the match is explicit, identity, exact, name or unmapped.
3. Send any important name or unmapped service to an administrator to add to the service map. Explicit mappings turn name matches into explicit ones for everyone.

Find the code behind a metric or an alert rule

1. In VS Code, ask CodeZero where a metric name from a panel or query is emitted, searching across every indexed repository.
2. Ask where an alert rule or dashboard is defined, if your team keeps them as code. Text search finds rule files and Helm or Terraform values even in repositories you have not cloned.
3. Use owners by commit history to find who to ask about an unwatched service or a stale rule.
4. To change a threshold or add a missing alert, describe the change. CodeZero plans it in the repositories that hold the config, and you approve the plan before anything is edited.

Vörr and CodeZero are separate products. You carry the finding from the assistant into VS Code; neither calls the other.

Without CodeZero or Vörr

Claude Code and ChatGPT can do a good share of this on their own. Vendor MCP servers, for example Grafana's or Datadog's, let Claude query that tool's metrics, logs, dashboards and alerts well. With kubectl or the AWS CLI credentialed on your machine, Claude Code can read pod status and CloudWatch metrics directly. ChatGPT reasons well over a pasted dashboard screenshot or alert payload.

The gaps are specific. Each tool needs its own server or CLI and its own credentials on the developer's machine. Each server sees one tool, so the assistant has to stitch the results together and decide what to do when they disagree. Service names differ between tools and nothing links them. An empty result looks the same as "healthy", "not connected" and "silenced" unless someone thinks to ask.

• Where AI engineering gets stuck

Three ways an unsupported health answer goes wrong

These are the failures that come up most when an assistant answers monitoring questions without context. The names and numbers are examples.

It guesses the service name

Checkout is checkout-svc in the metrics tool, web-checkout in the error tracker and deploy-checkout-prod in CI. The assistant queries "checkout", gets no series back or a different service whose name contains the word, and reports "no errors in the last 15 minutes". It has no list of real names, each tool names things its own way, and an empty result looks healthy. With Vörr, the name is resolved through the service map first, the real names can be listed per tool, and every result shows how it was matched.

It reports a false zero

Payments sends its logs to a different tool from the one the assistant can reach, so "any errors overnight?" returns nothing and becomes "no errors overnight". Most tool interfaces return an empty list for "nothing there", "you cannot see it" and "we did not look" alike. With Vörr, the answer names the sources that were queried, which ones have the capability, and which services nobody watches, so a verified zero is distinguishable from an unasked one.

It trusts one dashboard

The APM tool shows checkout's error rate at 4%. Prometheus shows 0.3%, because the two count retries differently. The assistant reports whichever tool it is connected to, or averages the two into a figure neither produced, with no hint that they disagree. With Vörr, each source is reported separately and never averaged, comparison windows flag the disagreement, and on AWS the CloudWatch baseline adds an independent verdict.

This is not a rare setup. Teams commonly run several observability technologies at once; the research page has the survey figures.

• What the research says

With CodeZero and Vörr

One question, every capable source (Vörr)

Health, metrics, alerts and dashboards from all connected tools in one answer, each result attached to its source and environment.

Names that line up (Vörr)

Service map resolution, real entity listing, and match quality on every result, so a name match is visible.

Verdicts, not just numbers (Vörr)

Comparison windows with disagreement flagged, and CloudWatch values judged against a 14-day baseline.

A coverage signal (Vörr)

Which sources can answer what, services nobody watches, and silences or failing rules that could make an answer wrong. "No connector" when nothing can answer.

No credentials on the laptop (Vörr)

Connections are made once by an administrator with read-only credentials. Stored credentials are never exposed to the assistant.

The code behind the signal (CodeZero)

Where a metric is emitted, where a rule or dashboard is defined, who owns it, across every indexed repository.

Reviewed monitoring changes (CodeZero)

Threshold changes and new alert rules as a plan naming the repositories involved, approved by you before edits, with only the declared verification commands running unprompted.

The combination matters most when a health check finds a gap. Vörr tells you a service has no latency alert and nobody watches its error rate. CodeZero finds where the team's other alert rules live, so you can add the missing one in the same place and the same style, through a plan you approve.

Worked example: the Monday health check

An SRE starts the week by checking the checkout service before a sale on Wednesday. They ask in Claude with the Vörr connector.

Service: checkout (production)

Source        Matched as        Match      Error rate     p95       p99       Throughput
Datadog APM   checkout-svc      explicit   1.9% (+1.4)    410 ms    1.8 s     220 rps
Prometheus    checkout          explicit   0.4% (+0.1)    380 ms    1.1 s     214 rps
CloudWatch    checkout-alb      name       5xx elevated   -         -         normal

Disagreement: Datadog and Prometheus disagree on error rate change (+1.4 vs +0.1 points).

Infra (Prometheus): CPU 41%, memory 78%, restarts 6 in 24h (all checkout-worker), pods ready 12/12

Alerts firing: none
Active silences: 1 in Alertmanager matching service=checkout, created 9 days ago, no expiry set
Rule health: CheckoutHighErrorRate failing to evaluate since last Thursday

Coverage: no SLO defined in any connected source; Sentry has no project matched to checkout (unmapped)

Reading the example

1. "No alerts firing" is not reassuring here. A nine-day-old silence covers checkout, and the high-error-rate rule has not evaluated since Thursday.
2. The sources disagree on the error-rate change. The SRE asks for the dashboard queries behind both: the APM tool counts client retries as errors and Prometheus counts only final responses. Both are right about what they measure, and the retries are new.
3. CloudWatch's elevated 5xx on the load balancer is a name match, so the SRE checks the load balancer name before relying on it. It is the right one.
4. Six restarts, all on checkout-worker, and memory at 78% point at the worker. A top-consumers query shows checkout-worker pods near their memory limit.
5. Sentry has no matched project, so the error tracker has said nothing because it was never asked, not because checkout is clean.

Conclusion: checkout is degrading in a way the alerting would not have reported. The worker is near its memory limit and retrying, the silence and the broken rule hid it, and the error tracker is not mapped.

Follow-ups from the example

1. Remove the stale silence in Alertmanager. That is a change in your alerting tool, made by you; Vörr is read-only.
2. In VS Code, ask CodeZero where CheckoutHighErrorRate is defined. It is in the platform-alerts repository, and the rule references a label renamed two weeks ago. Describe the fix, approve the plan and review the change before you commit it.
3. Ask CodeZero where the checkout-worker memory limit is set. It is in the Helm values in the deploy repository, not the service repository. Plan the change for approval.
4. Ask an administrator to map the Sentry project for checkout in the service map, then rerun the health check to confirm the match is explicit.
5. Raise the missing SLO with the service owner. For the incident path, if the worker starts failing before Wednesday, move to From incident to fix.

Verify and follow up

• Provenance: every figure should name its source and environment. Treat a figure without a source as unverified.
• Match quality: confirm inferred and unmapped matches before acting on them, and get important services mapped explicitly.
• Coverage: before reporting "healthy" or "no errors", ask which sources could answer, whether anything is silenced and whether any rule is failing.
• Disagreement: when sources disagree, read the queries behind each figure before choosing one.
• Reproduce: run the panel or the raw query yourself through Vörr, or in the tool, to confirm a surprising number.
• Code changes: for threshold or rule changes made through CodeZero, check the plan names the right repositories and that its verification commands, such as a rule linter, ran.

Next operations: if a check turns up a specific error, continue on Debug a production error. If it correlates with a deploy, use Investigate deployments and CI failures. If it is already customer-facing, go to From incident to fix.

Limits

• Vörr can only answer from tools that are connected. Coverage tells you what is missing; it cannot fill the gap.
• SLOs, release health and alert routing come from the connected tools that define them. Vörr reports them; it does not create them.
• Vörr is read-only from the assistant. It cannot silence an alert, change a threshold, restart a pod or edit a dashboard.
• Name matches can be wrong. They are labelled name for that reason, and the service map is maintained by administrators.
• The CloudWatch baseline covers AWS metrics. Other sources are compared using the windows you ask for.
• Log lines are redacted, which can hide a value you were looking for.
• CodeZero's search covers committed code on the default branch of indexed repositories, plus your local working trees. A rule changed directly in the alerting tool's UI and never committed will not be found there.
• CodeZero's references are matched by name, and callers are heuristic. Same-named metrics in different services can both appear.

Related

• Debug a production error
• From incident to fix
• Investigate deployments and CI failures
• Explore cloud infrastructure
• Answer system questions without the IDE
• Keep context across the team
• What the research says
• Ask Vörr about your system
• Connect observability and CI tools
• Vörr security and privacy
• Ask about your codebase in CodeZero
• CodeZero across multiple repositories
• CodeZero execution modes