Vörr (also written Vorr) connects your code, cloud, deployments, monitoring, incidents, and other engineering tools, allowing AI to answer questions using the reality of your systems instead of relying on prompts, assumptions, or incomplete context.
Vörr sits between your AI assistant and your engineering systems, continuously collecting and connecting the context needed to understand how your applications actually work.
ClaudeconnectedPOST /api/v1/orders/checkout latency jumped right after the new code was pushed — can you check Grafana and the latest commits and find why?
Yes — I checked Grafana, the latest deploy, and the commits pushed before the spike.
After the 11:42 AM deploy, p95 on POST /api/v1/orders/checkout rose 420 ms → 2.8 s within ~5 min.
Cause is commit 9f3a21c — add coupon validation before order creation: it moved coupon checks into the checkout flow, so pricing is now called once per cart item instead of once per order. For 8–12-item carts that's a burst of sequential GET /pricing/validate-coupon calls.
Root cause
Coupon validation runs sequentially per item instead of one batched call for the whole cart.
Where
services/checkout/src/checkout.service.ts → validateCouponForItems(cart.items)
Fix
Send the full cart, validate the coupon once, return the final discount — instead of looping per item. That brings checkout back near baseline.
✓ verified · Grafana · Git · checkout-api









Reads from the tools you already run (30+ Connectors)
Datadog
Sentry
OpenTelemetry
Jenkins
Jaeger
SigNoz
Prometheus
Grafana
Loki
Tempo
New Relic
Nagios
BugSnag
VictoriaMetrics
Grafana Mimir
Thanos
Elasticsearch
Splunk
Dynatrace
GrayLog
CircleCI
ArgoCD
Kibana
Uptime Kuma
Harbor
Flux CD
SonarQube
Alertmanager
Nexus Repository
Buildkite
Datadog
Sentry
OpenTelemetry
Jenkins
Jaeger
SigNoz
Prometheus
Grafana
Loki
Tempo
New Relic
Nagios
BugSnag
VictoriaMetrics
Grafana Mimir
Thanos
Elasticsearch
Splunk
Dynatrace
GrayLog
CircleCI
ArgoCD
Kibana
Uptime Kuma
Harbor
Flux CD
SonarQube
Alertmanager
Nexus Repository
BuildkiteThe tools live at GenAI's end. Same question, same sources — the only difference is what GenAI has to choose from.
api.js, and the related config file. Can you check these and tell me what exactly is causing the error?api.js— but I'm limited to these snippets. The config references env vars I can't resolve, and I don't have the full stack trace or the requests that triggered each error, so I can't pin the exact line or rule out a DB timeout vs. a null value vs. a bad config. My best guess is a missing credential in the config or an unhandled rejection in a handler. To be sure, you'd need to line the Sentry events up with the actual deploy and the live config — which I can't see from here.POST /api/orders/checkout — Sentry logged 214 events in 3h, every one identical: TypeError: cannot read 'id' of undefined at api.js:142 in createOrder().Root cause — session.user is undefined. The auth middleware was dropped from this route in PR #391("simplify checkout flow", merged 4h ago), so the session never gets populated.GitHub — the diff removes requireAuth from routes/orders.ts:23; the 500s start at the exact deploy timestamp.Fix: re-add requireAuth on the /checkout route, or guard session.user before api.js:142.worker_connections or upstream keepalive), a small DB connection pool, or blocking I/O downstream. But I only have the access log and nginx.confyou pasted — I can't see your app's pool settings, DB metrics, or thread state under load, so I can't tell which limit you're actually hitting. You'd have to check those yourself while reproducing the load.payments-api pool is capped at 20 (db/pool.ts:14), and Datadog shows p95 on /api/orders jumping 180 ms → 2.7 s the moment active DB connections hit 20/20 and requests start queuing.Nginx is fine — worker_connections 1024, only ~12% used at peak, so it isn't the limiter.Postgres — max_connections is 100, of which other services already hold ~40, leaving room to grow the pool safely.Fix: raise the pool max (start at 50) and add a queue timeout in db/pool.ts:14, then re-run the load test.CrashLoopBackOff. I'm sharing the pod error logs below. Can you check the logs, identify why the pod is failing, and give me the exact steps to fix it?CrashLoopBackOff just means the container keeps failing and restarting — the real cause is the exit reason, which this log doesn't show. Killed with no message could be an OOM kill, a failed liveness probe, or the process receiving a signal; I can't tell which from the snippet alone. I also can't see the resource limits, the deployment manifest, or recent changes. You'd need to run kubectl describe pod (check Last State / Reason — e.g. OOMKilled vs Error), kubectl logs --previous, and review the probe and limit config — none of which I can do against your cluster from here.payments-worker-7c9f is being OOMKilled. kubectl describe shows Last State: Terminated, Reason: OOMKilled, Exit Code 137 — it's crashed 9 times in 20 min.Root cause — its memory limit is 256Mi (payments-worker.yaml:38), but the batch job added in PR #402 loads the full invoice set into memory and peaks at ~410Mi.Jenkins — that change deployed 35 min ago, exactly when the crashes began.Fix: raise the limit to 512Mi at payments-worker.yaml:38, or stream the invoices in batches in worker/invoices.ts:60 instead of loading them all at once.
Claude
ChatGPT
Codex
Claude Code
CursorVörr, also written Vorr or Vor, is an AI context engine for engineering teams. It connects your code, cloud infrastructure, observability and CI data into one traceable context, so AI assistants like Claude and ChatGPT can answer questions using the real state of your systems.
Yes. You add Vörr to Claude or ChatGPT as a custom connector using its MCP URL, and ask your questions in that assistant. The Vörr web app is where you connect your systems and browse Cloud Mapping, scan results and Architecture.
No. Vörr is read-only by design. It uses read-only credentials, never pushes code, and doesn't change your infrastructure, repositories or CI. Scans discover and map resources without modifying them.
No. Connecting Vörr to Claude or ChatGPT needs an explicit consent step tied to your user and organisation. The assistant can retrieve facts, but Vörr's stored cloud, Git and observability credentials are never exposed to it.
AWS, Google Cloud and Azure; GitHub, GitLab and Bitbucket; plus connectors for observability and metrics, error tracking, distributed tracing, logs and CI/CD. Prometheus and Nagios can be added during cloud setup.
Only if that area was scanned successfully. Vörr separates a scanned-and-empty result from a resource type it doesn't index and from a scan that was incomplete because of access, failure or throttling, and tells you which one you're looking at instead of reporting a false zero.
No. Vörr indexes committed code in the repositories you connect. Local, uncommitted work on a developer's machine is never read.
Your first 1k tool calls are free, with no credit card required. After that, Cloud plans are usage-based, or you can run Vörr fully self-hosted with BYOC.
This entire page is built by Vörr AI.
Hi — I'm the Vörr assistant. Ask me how Vörr works, how it compares to wiring up raw MCPs, how it keeps your data safe, or what it can answer about your stack. If you'd rather talk to an engineer, I'll point you the right way.