Signals

A signal is one query on one of your cloud accounts or integrations that watches one operation of your application: a request route, a job, a queue consumer, a model call, a named step. It counts the failures, the successes, the volume or the latency of that operation, in the telemetry that the connection really carries. Signals show you whether each part of your application does its work.

What it does

Polylane reviews the cloud accounts and integrations of your workspace every day. Each team instruments its code in its own way, so Polylane learns the conventions of each connection before it writes a query:

1. It reads the code in your repositories: the entry points, and how the code logs, traces and counts.
2. It reads samples of real events and spans from the connection.
3. It records a profile of the telemetry: how the code is instrumented, the keys that name an event, the keys that tell success from failure, and the keys that narrow events to one operation. When your team calls its event field action, the profile says action.
4. It writes the signals of the connection with those keys, in the query language of the provider.

Polylane runs every query before it keeps it, so a signal is only kept when it returns real data. A signal must name a key or an event from the profile, so each signal watches one operation and not all the telemetry of the connection. A connection has at most 120 signals.

Each signal runs on the check frequency of its connection, with the same baselines and checks as the rest of detection. When a signal changes for the worse, Polylane opens an issue on that cloud account or integration, and its fix run gets the operation and the query.

When the telemetry of a connection cannot see the operations of your application, Polylane writes no signal for it. The discovery thread says what is missing, for example "the logs contain only request lines with no route or status".

Signals from earlier Issues

Polylane also reads confirmed Issues from the last 30 days. When a connection query can identify an Issue's cause, Polylane writes a signal for it. A signal links to its source Issue. Polylane can detect the same problem early if it returns.

When it runs

Discovery runs once a day. Your first run starts when you connect the first cloud account or integration that can answer signals. Each run reviews up to 12 connections, starting with the connections that have the fewest signals. The next daily run continues with the others.

To start a run immediately, for example after you connect something new, select Discover now on the Signals page. A run takes some time, and the page shows when the run started. You can start a new run 30 minutes after the last one.

Polylane keeps a signal while its query is the same, so its baseline continues from one run to the next.

Where to find it

• Signals in the console sidebar lists the signals of the workspace with their connection, operation, role and origin. Select a signal to see its query and why it matters.
• The Signals tab on a cloud account or integration page lists the signals that read the telemetry of that connection.
• Each discovery run opens one thread for each cloud account or integration it reviews, named Signals: <connection>, so you can read what Polylane checked for that connection.
• Agents read the same signals in any thread, so you can ask which signals watch a failing operation.

Signals come from AWS, Cloudflare, Vercel, Fly.io, Render, Supabase, Railway and Trigger.dev accounts, and from Datadog, Sentry, Honeycomb, Axiom, Mixpanel, PostHog, Grafana, Logfire, LangSmith and New Relic integrations. Discovery uses only the connections that every member of the workspace can see. A connection with anomaly checks turned off is not used.

Related

• Issues for what happens when a signal changes for the worse.
• Billing and usage for when background work, signal discovery included, pauses on a Free workspace.