Answer system questions without the IDE

When you'd do this

• You're on call, away from your desk, and want to know whether checkout is erroring and what deployed in the last hour before you open a laptop.
• A support ticket mentions an error message and you want to know which service produces it and whether it's happening a lot, without pinging an engineer.
• A manager needs to know which team owns a service, whether it's internet-facing and roughly what it costs, for a review that starts in ten minutes.
• An alert fired in a channel and nobody remembers what the rule actually measures or what its threshold is.
• You're an engineer on a different team and want to know what depends on a service before you file a request against it.
• Product wants to know whether a fix has shipped to production, and where the behaviour lives in code.

Before you start

• Your organisation has Vörr set up, with at least the code repositories connected. Each further answer type needs its own source: cloud accounts for where things run and AWS cost, observability tools for health, alerts and dashboards, and CI/CD tools for deploys.
• You use Claude, ChatGPT or another MCP assistant on a plan that supports custom connectors. Once the connector is on your account, you can ask from any app of that assistant that supports connectors, including on a phone if your plan allows it. ChatGPT needs a paid plan with Developer mode turned on.
• Vörr answers from the organisation's connected sources, and workspaces label what comes back. Admins manage connections and the service map.
• You don't need CodeZero, an IDE, a checkout, or any cloud or tool credentials. Everything on this page is read-only.

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

• Add Vörr to Claude or ChatGPT
• Roles and permissions

Why a general assistant isn't enough

An assistant without access to your systems describes how a service like yours usually works, not how yours does. The answer reads well, and it's often wrong in the details that matter: the timeout is set by an environment variable rather than in code, a second service writes the same table, or the deploy went to staging but not production.

Names are the other trap. The same service can be checkout in the service catalogue, checkout-svc in Kubernetes and web-checkout in the error tracker. An assistant that guesses one name and queries a tool with it gets nothing back, or gets a different service, and reports that as the answer. Vörr resolves the name you use through the service map, then confirmed aliases, then catalogue names, and only then the raw name. It can list the real entity names in each tool, and every result says how well it matched.

Operations

These are the question types people ask most. Each one lists what Vörr does and what the assistant does, gives prompts you can copy, and says what a good answer looks like. Start a prompt with "Using Vörr" so the assistant uses the connector instead of answering from memory.

1. Connect and check what you can see

1. You: in Vörr, open Chat and choose Connect with Claude or Connect with ChatGPT. Copy the MCP URL it shows.
2. You: in the assistant, add a custom connector with that URL. In Claude it's Settings → Connectors → Add custom connector.
3. Vörr: your browser opens the consent screen. Sign in, review the access and choose Allow. The authorisation belongs to your user and organisation, and every person who wants to ask questions connects their own account.
4. Vörr: the assistant never sees the cloud, Git or observability credentials Vörr holds. It gets answers from the organisation's connected sources, with workspaces labelling what comes back.
5. You: ask a first question that only your organisation's data can answer, and check which sources are connected.

The connection works when the answer names your real services and resources, with Vörr as the source. If it says nothing is connected, the setup isn't finished; ask your admin. To remove access, delete the connector in the assistant's settings. Nothing inside Vörr changes when you do.

2. Find where something is configured or implemented

1. Vörr: searches code across the connected repositories, including repositories you have never cloned, and reads the matching files with their repository and path.
2. Vörr: for configuration, it finds where a setting is defined in code and where .env.example and deployment config set it. For endpoints, it lists the HTTP routes each repository declares.
3. Assistant: puts the pieces together, for example where a value is read, where its default is set and which deployment setting overrides it.

A good answer gives a repository and file for every claim. The index covers committed code on the default branch, so work in progress on a branch won't appear. If the search found nothing, ask which repositories were searched before you conclude the code doesn't exist.

3. Find what a service depends on and what depends on it

1. Vörr: from connected tracing tools, returns the service graph: who calls the service and what it calls.
2. Vörr: where cloud accounts are connected, returns the resource's one-hop neighbours with a confidence level, and the precomputed upstream and downstream blast radius with true counts.
3. Vörr: searches code for clients, URLs and queue names when runtime data doesn't cover a link.
4. Assistant: separates what came from runtime data, cloud scans and code, and says which is which.

Runtime data only shows calls that actually happened in the window it covers. Cloud data only covers scanned accounts. If a link matters for a decision, ask for its evidence. For the full method, including code-level impact across repositories, see Understand system architecture.

4. Check whether something is healthy right now

1. Vörr: returns up/down status, error rate, p95 latency (plus p50 and p99 where the source reports them) and throughput from each connected source. Sources are reported separately and never averaged together.
2. Vörr: adds infrastructure signals where they exist (CPU, memory, restarts, pods ready), SLOs and error budgets, firing alerts and the top error issues with counts.
3. Vörr: compares against an earlier window on request and flags where sources disagree. For AWS, CloudWatch metrics are checked against a 14-day baseline and classed as normal, elevated or unprecedented, or unknown where there is no baseline yet.
4. Assistant: summarises in two or three lines, naming the source of each number.

If two sources disagree, report both rather than picking one. If an alert source has silences or failing rules, Vörr's coverage check can say so, which is a reason the picture could be wrong. For a structured routine, see Monitor service health; for chasing a specific error, see Debug a production error.

5. Find what deployed recently, and where

1. Vörr: returns the organisation-wide deploy feed across the connected CI/CD sources, per service, and per environment where the source reports one (GitHub Actions, GitLab and Bitbucket don't), with regression windows Vörr detects (with Grafana connected), shown alongside deploys.
2. Vörr: tells you which branch deploys to which environment, so "merged" and "live in production" aren't confused.
3. Vörr: for a failed CI build, returns a diagnosis of the most recent few failed builds from the logs: category, phase, reason, an excerpt, and the failing test names where the CI source reports them (Jenkins, CircleCI, Buildkite and Drone).

Ask which CI/CD sources were checked. A team that deploys with an unconnected tool is invisible in the feed, and "nothing deployed" can mean "nothing we can see". For a full failed-deploy investigation, see Investigate deployments and CI failures.

6. Find who owns something

1. Vörr: reports the workspace each repository or cloud resource is mapped to. Workspaces are how your organisation records team ownership in Vörr.
2. Vörr: reports who has committed most to a repository or path, from commit history.
3. Vörr: for cloud resources, shows customer tags and fg: tags, which often carry a team or cost-centre tag, and flags resources that aren't mapped to a workspace.

Commit history tells you who has been active, not who is accountable. A repository in no workspace, or in the wrong one, is worth flagging to your admin.

7. Find where something runs and whether it's internet-facing

1. Vörr: searches scanned AWS, Google Cloud and Azure resources by type, region, account, tag, exposure and mapping status.
2. Vörr: for one resource, returns its scanned configuration, the workspace and environment it maps to, its tags and whether it's managed by Terraform.
3. Vörr: classes exposure as public, private, isolated or unknown, by walking from the service to its host or network interface, its security groups and the load balancers in front of it.

An exposure answer is only as good as the scan. Ask for scan coverage when the answer is "nothing is public": access denied, failed or throttled services mean parts of the account weren't seen. For a deeper walk through accounts, see Explore cloud infrastructure.

8. Find out what an alert or dashboard panel actually measures

1. Vörr: for an alert, returns the rule, its threshold, its firing history, where it routes and any active silences.
2. Vörr: for a dashboard, lists the panels with their underlying queries, and can run a single panel to show its current values.
3. Assistant: explains the query in plain language: which metric, which filter, which aggregation, over what window.

Panels and alerts often measure something narrower than their title, such as one region, only 5xx responses or a single endpoint. Quote the query when you share the answer, so nobody reads more into the number than it holds.

9. Find out what something costs (AWS)

1. Vörr: returns the AWS spend breakdown and trend, by service and dimension, with a coverage status.
2. Vörr: lists waste patterns and savings opportunities, such as Graviton, gp3, spot, commitments and rightsizing.
3. Assistant: puts the figures in context and says what the coverage status means for their accuracy.

Cost is AWS only. For Google Cloud or Azure, Vörr can tell you what runs where, but not what it costs. Attributing spend to a service depends on tags and workspace mapping, so ask how the figure was attributed. For acting on cost, see Reduce cloud cost.

10. Find the real name of a service in each tool

1. Vörr: resolves the name you used through the service map, confirmed aliases and catalogue names before falling back to the raw name.
2. Vörr: lists the real service, job and project names each connected tool knows, so you can pick the right one when the match isn't explicit.

Use this when an answer comes back empty, or when the match quality is name, suggested or unmapped. If a name only ever gets a name match, ask your admin to add it to the service map so it resolves explicitly for everyone.

How to read an answer

Before you rely on an answer or pass it on, check these five things. They're in every Vörr result; if the assistant leaves them out of its summary, ask for them.

Source

Which tool, repository or cloud account each fact came from. A number with no source is the assistant's, not Vörr's.

Match quality

Explicit means the service map links your name to the result; identity and exact mean a confirmed alias or a catalogue name. Name means a raw-name hit, suggested means Vörr proposed the match, and unmapped means nothing matched. Check name, suggested and unmapped matches before acting.

Environment

Production, staging or something else. A healthy staging service says nothing about production.

Coverage

Whether the relevant scan or source was complete. "No resources found" only means something when the area was scanned successfully.

No connector

No connected source can answer this kind of question. It isn't a zero, and it isn't an error. It means you need another source connected, or someone with direct access.

Asking good questions

• Name the service, the environment and the time window: "checkout, production, last 30 minutes" beats "is checkout OK".
• Ask for sources and match quality in the prompt itself, so they appear in the summary.
• Ask what can't be concluded: which sources weren't connected, which scans were incomplete and which links were inferred.
• Keep one question per prompt for anything you'll share. Broad questions produce broad summaries.
• Use follow-ups to drill from a summary into evidence: the file, the query, the deploy, the resource configuration.

Sharing answers safely

• Vörr redacts log lines and error samples before returning them, but no redaction catches everything. Read anything from logs or errors before you paste it into a ticket or a public channel.
• Answers come from the organisation's connected sources, and workspaces label what comes back. The recipient may not have Vörr connected, so share the conclusion and its sources rather than assuming the recipient can rerun it.
• Check before forwarding. An answer with name matches, partial coverage or "no connector" in it should say so when it's shared; don't round it up to a firm conclusion.
• Save conversations you'll need later. Unsaved conversations expire after seven days.

When to hand off to an engineer

Vörr is read-only from the assistant. It can't change code, configuration, infrastructure, alerts or tickets, and no change is made to your systems from chat. When an answer leads to a change, the next step belongs to an engineer.

Hand off with the question, the answer, its sources and anything that couldn't be concluded. The engineer can then pick it up in CodeZero, which searches the same organisation index from VS Code, adds inferred links between repositories (each with file:line evidence, and a confidence on HTTP and config links), and turns the change into a plan that the agent can't approve itself.

• The answer points at a bug or a misconfiguration that needs fixing.
• An inferred link or match is central to a decision and needs checking at the call site.
• Vörr said "no connector" or showed partial coverage, and someone with direct access has to look.
• The question is about uncommitted work or a branch, which the index doesn't cover.

• CodeZero Chat
• Execution modes

Without CodeZero or Vörr

Claude or ChatGPT with a GitHub connector can search and read code in the repositories your account can access, and answer "where is X" questions well there. Web search covers vendor documentation. Pasted logs, screenshots of dashboards and stack traces get a careful reading. An engineer with Claude Code in a checkout can also run gh, kubectl or aws if they're installed and credentialed on that machine. The gaps are about what each tool can reach, not about reasoning.

Done alone, every answer type needs its own connector or CLI, credentials for each, someone who knows which repositories and tools exist, and the patience to reconcile service names between them. That's usually the engineer you were trying not to interrupt.

With CodeZero and Vörr

Vörr: one connector, many sources

Code, cloud, monitoring, errors, logs, traces, alerts, dashboards, deploys and AWS cost from more than 30 tools, through a single connector you add once, from any device the assistant runs on.

Vörr: names that resolve

Service map, aliases and catalogue names turn the name you use into the right entity in each tool, and every result says how well it matched.

Vörr: honest gaps

Coverage, match quality and "no connector" tell you when an answer is partial, rather than turning missing data into a zero.

Vörr: safe by default

Read-only from chat, per-user consent, workspace labels on every answer, no credentials exposed to the assistant.

CodeZero: the engineer's side

When an answer leads to a change, an engineer uses CodeZero in VS Code to verify inferred links at the call site and plan the change across repositories. The two products sit side by side; CodeZero doesn't call Vörr.

Worked example: an alert at dinner

An on-call engineer gets a CheckoutHighErrorRate alert on their phone while away from their laptop. They open Claude on the phone, where Vörr is already connected, and work through operations 8, 4 and 5.

Alert: CheckoutHighErrorRate (Prometheus / Alertmanager)
  rule: 5xx / all requests on checkout-svc, eu-west-1 only, 5m window
  threshold: > 2% for 10m      fired 3 times in 30 days
  routes to: #payments-oncall   silences: none

Health, checkout, production, last 15m vs same time yesterday
  match: checkout -> checkout-svc (explicit), web-checkout (Sentry, name)
  Prometheus   5xx rate 3.4% vs 0.3%   p95 820 ms vs 310 ms
  Datadog      error rate 3.1% vs 0.4%
  Sentry       top issue: UpstreamTimeout payments-api, 1,284 events (new)

Deploys, last 2h
  payments-api   production   19:42   Argo CD
  checkout-svc   none

Regression windows (Grafana)
  payments-api   production   from 19:44   5xx rate up

Coverage
  Prometheus: answered   Datadog: answered   Sentry: answered   Argo CD: answered
  Tracing: no connector

What the on-call engineer concludes

The alert is real and agrees across sources: errors and latency are up on checkout in eu-west-1, and the top new error is a timeout calling payments-api. payments-api deployed at 19:42, and Vörr shows a regression window on it starting two minutes later; checkout didn't deploy. The likely cause is upstream, not checkout itself.

What can't be concluded: there's no tracing connector, so the call path from checkout to payments-api is inferred from the error, not observed. The Sentry match is by name only, so they check that web-checkout really is the production checkout service before quoting it.

Follow-ups: they post the summary to #payments-oncall with the sources and the "no tracing" caveat, page the payments-api owner (the Payments workspace), and save the conversation. Back at a laptop, the payments engineer opens the regression in CodeZero and follows Debug a production error.

Verify and follow up

• Every code fact should name a repository and file, every number a tool, and every cloud fact an account and scan.
• Check match quality on anything you'll act on. Name, suggested and unmapped matches deserve a follow-up question or a look at the real entity names.
• Check the environment and time window match what you asked for.
• Treat "no connector", partial coverage and incomplete scans as part of the answer, and say so when you share it.
• Remember the code index is committed code on the default branch.
• For deeper work, move to the activity page: Debug a production error, Monitor service health, Explore cloud infrastructure or Plan product work.

Limits

• Vörr only knows what has been connected and scanned. Each answer type needs its source connected by an admin.
• It's read-only from the assistant. It doesn't change code, infrastructure, alerts or tickets, and it doesn't write tags from chat.
• Cost data is AWS only.
• The code index covers committed code on the default branch, not branches or uncommitted work.
• Dependencies from tracing reflect observed traffic in the window queried. Inferred links and matches can be wrong and say so.
• Ownership comes from workspace mapping and commit history, not from an accountability policy.
• Log lines and error samples are redacted, but redaction can miss things. Read before you forward.
• The assistant does the reasoning and the summary. Vörr supplies the facts, so an assistant can still summarise badly; that's why the sources matter.

Related

• Plan product work
• Debug a production error
• Monitor service health
• Explore cloud infrastructure
• Investigate deployments and CI failures
• Understand system architecture
• Reduce cloud cost
• Where AI engineering gets stuck
• Add Vörr to Claude or ChatGPT
• Ask Vörr about your system
• Connect observability tools
• Roles and permissions
• Security and privacy
• CodeZero Chat