Dashboard

Le travail d'infrastructure pour lequel personne n'a été embauché. Cartographié, surveillé et tenu à jour par des agents.

Rejoindre la liste d'attente

Un seul graphe, tous les fournisseurs. Pas un schéma que tu maintiens : un graphe qui se synchronise tout seul.

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

Chaque changement est consigné. Douze minutes avant la régression, quelqu'un a touché la file d'attente.

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

Les parties silencieuses, surveillées. Le cron bloqué, le backlog qui grossit, le worker qui s'est arrêté.

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

Comment Polylane fonctionne. Il apprend ton système, le surveille, enquête et agit.

  • Il apprend d'abord ton système

    Le graphe de contexte cartographie chaque ressource et chaque dépendance à travers tes clouds, tes dépôts et tes fournisseurs d'observabilité. Les agents raisonnent sur une topologie réelle, pas sur des suppositions.

  • Détection sans seuils

    Des vérifications intégrées pour chaque fournisseur, plus des vérifications générées à partir de tes propres requêtes enregistrées et de tes dashboards. Une passe statistique et un agent décident ensemble, et une amélioration ne lève jamais d'issue.

  • Des enquêtes qui montrent leurs preuves

    Chaque affirmation renvoie à la requête, à la ligne de log ou à l'enregistrement de changement qui la fonde. Un verdict sans preuves retombe sur non concluant.

  • Les écritures se méritent, jamais présumées

    Les comptes se connectent en lecture seule. Les rollbacks sont désactivés par défaut, limités en fréquence et consignés. Les changements de code passent par ta revue habituelle.

  • Il s'affûte chaque semaine

    Mémoires, notes quotidiennes et requêtes de supervision reconfirmées contre des données réelles : l'enquête de juillet apprend de celle de juin.

Il se branche sur ce que tu fais déjà tourner. Connecte en lecture seule et commence.

Questions.

Quels fournisseurs Polylane prend-il en charge aujourd'hui ?

AWS, Cloudflare, Vercel, Render, Fly.io, Kubernetes, PlanetScale, Supabase et Modal, plus GitHub pour le code et Datadog, Honeycomb, Axiom, Grafana Cloud et Sentry pour la télémétrie. La page des intégrations suit le catalogue complet, y compris ce qui arrive ensuite.

Comment relie-t-il les ressources entre les clouds ?

Comme le trafic circule vraiment : noms d'hôtes, enregistrements DNS et adresses IP rapprochés entre fournisseurs, variables d'environnement qui révèlent des dépendances, traces là où tu en as, et infrastructure-as-code qui déclare ce qui se déploie où.

Dois-je tagger les ressources ou dessiner la topologie ?

Non. Connecte chaque compte en lecture seule et le graphe se construit et se maintient tout seul. Tu peux corriger ou annoter n'importe quoi, et les agents le gardent à jour à chaque synchronisation.

Quel niveau d'accès chaque cloud demande-t-il ?

Le minimum, en lecture seule par défaut : AWS via un rôle CloudFormation à périmètre restreint, Cloudflare via des permissions de token préremplies, et des équivalents partout ailleurs. L'accès en écriture est une décision séparée, compte par compte.

Quels systèmes de fond surveille-t-il ?

Tout ce que tes fournisseurs font tourner : files SQS et tâches planifiées sur AWS, Cloudflare Queues, workers de fond et tâches cron Render, CronJobs Kubernetes, machines Fly.io. Si c'est dans un compte connecté, c'est dans le graphe.

Plus de cas d'usage

Connecte tes clouds. Le graphe se construit tout seul.