Dashboard

Die Infrastrukturarbeit, für die niemand eingestellt wurde. Kartiert, beobachtet und ehrlich gehalten von Agenten.

Auf die Warteliste

Ein Graph, jeder Provider. Kein Diagramm, das du pflegst: ein Graph, der sich selbst synchronisiert.

Topology
Search your cloud resources...
Galaxy
checkout-edge Worker
Critical Critical to your architecture.

Issue hotspot: 4 issues in the last 7 days

Change hotspot: 12 changes in the last 7 days

Cloudflare · coreplane · earth · Compute
hd-prod Hyperdrive
Critical Critical to your architecture.

Change hotspot: 7 changes in the last 7 days

Cloudflare · coreplane · earth · Databases
ingest-events Lambda function
Standard Important to your architecture.

Issue hotspot: 2 issues in the last 7 days

AWS · coreplane-prod · us-east-1 · Compute
payments-db Database
Critical Critical to your architecture.

Issue hotspot: 1 issue in the last 7 days

Change hotspot: 3 changes in the last 7 days

PlanetScale · coreplane · us-east · Databases

Jede Änderung wird protokolliert. Zwölf Minuten vor der Regression hat jemand die Queue angefasst.

Clouds prod-aws Changes

SQS visibility timeout lowered on checkout-events

Moderate impact configuration ·Synced 12 minutes ago

VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.

What we're watching
ApproximateAgeOfOldestMessage
checkout-events · baseline at change 3.2s · worse if up
Watching: no issue since this change
NumberOfMessagesReceived
checkout-events · baseline at change 41/min · worse if up
Watching: no issue since this change
Triggering events
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window
Full diff (3 changes)
Nodes (2) Edges (1)
2 nodes modified · 1 edge removed

Die stillen Teile, beobachtet. Der hängende Cron, der wachsende Rückstau, der Worker, der stehen geblieben ist.

Issues reconcile-orders stopped running Overview

reconcile-orders stopped running

High Incident ·Detected by Polylane
OverviewMetricsLogsTracesTimelineProperties
What changed
  • runs/day 4 → 0: no successful run since Tue 02:00 UTC
  • last attempt exited with code 137 after 91s (Tue 02:01)
  • peak memory on the final run was 2.4× the previous seven-day average
Why it matters

Orders placed since Tuesday have no reconciliation record. The finance export and the daily revenue report both read from the table this job writes.

Suggested investigation steps
  1. 1. Read the logs from the last attempt on reconcile-orders
  2. 2. Check for memory limit or plan changes on the service in the change records
  3. 3. Confirm the schedule still exists in render.yaml on main
Investigate Detected 02:31 UTC · 30 minutes after the missed run

So funktioniert Polylane. Es lernt dein System, beobachtet es, untersucht und handelt.

  • Es lernt zuerst dein System

    Der Context Graph kartiert jede Ressource und Abhängigkeit über deine Clouds, Repos und Observability-Provider. Agenten denken über echte Topologie nach, nicht über Vermutungen.

  • Erkennung ohne Schwellenwerte

    Eingebaute Checks für jeden Provider, plus Checks aus deinen eigenen gespeicherten Queries und Dashboards. Ein statistischer Durchgang und ein Agent entscheiden gemeinsam, und eine Verbesserung löst nie ein Issue aus.

  • Untersuchungen mit Belegen

    Jede Behauptung verweist zurück auf die Query, die Logzeile oder den Änderungseintrag dahinter. Ein Urteil ohne Belege fällt auf unentschieden zurück.

  • Schreibzugriff wird verdient, nie vorausgesetzt

    Konten verbinden sich nur lesend. Rollbacks sind standardmäßig aus, ratenbegrenzt und protokolliert. Codeänderungen gehen durch dein normales Review.

  • Es wird jede Woche schärfer

    Memories, tägliche Notizen und Monitoring-Queries, gegen echte Daten neu bestätigt: Die Untersuchung im Juli lernt von der im Juni.

Es steckt sich in das, was du schon betreibst. Nur lesend verbinden und loslegen.

Fragen.

Welche Provider unterstützt Polylane heute?

AWS, Cloudflare, Vercel, Render, Fly.io, Kubernetes, PlanetScale, Supabase und Modal, plus GitHub für Code und Datadog, Honeycomb, Axiom, Grafana Cloud und Sentry für Telemetrie. Die Integrationsseite führt den vollständigen Katalog, inklusive dem, was als Nächstes kommt.

Wie verknüpft es Ressourcen über Clouds hinweg?

So, wie der Traffic tatsächlich fließt: Hostnames, DNS-Einträge und IP-Adressen über Provider hinweg abgeglichen, Umgebungsvariablen, die Abhängigkeiten verraten, Traces, wo du sie hast, und Infrastructure-as-Code, das deklariert, was wohin deployt wird.

Muss ich Ressourcen taggen oder die Topologie zeichnen?

Nein. Verbinde jedes Konto nur lesend, und der Graph baut und pflegt sich selbst. Du kannst alles korrigieren oder annotieren, und Agenten halten ihn mit jedem Sync aktuell.

Wie viel Zugriff braucht jede Cloud?

Das Minimum, standardmäßig nur lesend: AWS über eine gescopte CloudFormation-Rolle, Cloudflare über vorausgefüllte Token-Berechtigungen und Entsprechendes überall sonst. Schreibzugriff ist eine separate Entscheidung pro Konto.

Welche Hintergrundsysteme beobachtet es?

Was deine Provider eben betreiben: SQS-Queues und geplante Jobs auf AWS, Cloudflare Queues, Render-Hintergrund-Worker und Cronjobs, Kubernetes-CronJobs, Fly.io-Maschinen. Ist es in einem verbundenen Konto, ist es im Graph.

Weitere Anwendungsfälle

Verbinde deine Clouds. Der Graph baut sich selbst.