A connection only earns its keep if it keeps working after you set it up. This page explains how the platform watches a connection's health in the background, what its status actually means, how to fix one that breaks, and what you can configure on a connection beyond its credentials.
Overview
Every connection carries a status of either Active or Inactive. The platform keeps that status accurate on its own — running periodic checks, refreshing tokens, and flipping a connection to Inactive when it can no longer authenticate. Separately, each connection has a Settings tab for telemetry, and a Details screen where you can add optional rate limiting and failure protection. Together, health monitoring and settings determine how reliably a connection behaves day to day.
Connection status: Active vs. Inactive
A connection is Active when it's authenticated and usable — automations and apps can run through it. It's Inactive when it can't be used, either because someone disconnected it deliberately, or because the platform disabled it after its credentials stopped working. Status reflects current health, not a one-time setup check, since the platform keeps re-testing connections in the background. An Inactive connection blocks anything that depends on it until you re-authenticate it.
How the platform checks your connection's health
For credentials that don't expire on their own — API keys, passwords, and similar — the platform runs a periodic health check: a lightweight test call to the app confirming the credentials still work. While checks pass, the connection stays Active and gets re-checked on a regular cadence, roughly every five minutes by default. When a check fails, the platform retries with growing wait times, and after five consecutive failures it marks the connection Inactive so you know it needs attention. That's why a connection that worked fine last week can suddenly show Inactive today — a key was revoked or the app became unreachable, and the health check caught it.
Connections that use expiring access tokens (OAuth) are handled differently: the platform refreshes the token automatically, both on a background schedule and on demand right before the connection is used. You don't need to re-authenticate for routine token expiry. If a refresh attempt genuinely fails — access was revoked, or the refresh token itself expired — the platform retries a few times and then marks the connection Inactive, the same way a failed health check does.
Diagnosing a failed connection
Common causes of a failure include an expired or revoked token, a changed password or rotated API key, insufficient permissions or scopes, or the target app being unreachable. To see the specific reason, open the connection for editing and either run Test Connection (for key or password-style authentication) or re-run the authorization flow. Any failure surfaces as an error banner on the form, usually naming the cause directly — an authentication error versus a network error, for example. The connection's Activity tab also shows when it was disabled, which helps you correlate the failure with something that changed around that time.
Reconnecting a connection
When a connection shows Inactive, open it for editing — its credential fields unlock so you can fix them:
API key or password: enter the new value, then select Authorize. The platform tests the credentials first and only saves them if the test passes.
OAuth: select Authorize or Re-authorize to run the app's login-and-consent flow again.
On success, the connection returns to Active and everything depending on it resumes working. If a connection still shows Active but you already know its credentials are bad, its fields stay locked while Active — select Disconnect first to clear the authentication and flip it to Inactive, then re-enter working credentials. Reconnect promptly, since anything depending on an Inactive connection fails until it's healthy again.
Monitoring health across all connections
Beyond checking one connection at a time, the Connections area includes an Insights tab — a dashboard summarizing health and usage across all your connections, so you can spot a problem proactively, such as a wave of failures right after an app changed its authentication requirements, instead of finding out only when an automation errors. Viewing Insights requires the view-insights permission for connections. For a single connection, check its status in the list and use Test Connection; for the full picture, use Insights. The Status column on the connections list is also sortable, so you can surface every Inactive connection at a glance.
Connection settings and telemetry
A connection's own Settings tab configures telemetry — the usage metrics collected for that connection. You can define custom metrics, including a name, what to measure, when to publish it, tags, and histogram buckets, that feed your observability dashboards. Behavioral options like rate limiting and failure protection live on the connection's Details screen instead, alongside its credentials.
Rate limits and circuit breakers
For connectors that support throttling, the Details screen offers two optional policies:
Rate Limit Policy — caps how many requests the connection sends in a time window (per minute, hour, or day), so busy automations stay within the app's documented limits instead of getting throttled or blocked.
Circuit Breaker — pauses requests automatically when too many are failing or running slow, based on configurable failure-rate and slow-call thresholds, so a struggling app gets breathing room and your runs fail fast instead of hanging.
Most connections work fine without either. Reach for them when an app enforces strict rate limits or tends to be flaky. You can set them while creating the connection, or add them later by editing it.
The Connections manager also has its own global Settings tab, next to Connections and Insights, with default telemetry settings that apply across all connections. A connection's own Settings tab overrides the global default for that connection. Viewing and editing the global tab requires the view-settings permission for connections — use it to set a sensible baseline once, and adjust per-connection settings only where a specific connection needs something different.
Notes
A connection needs five consecutive failed health checks (or refresh attempts) before it flips to Inactive — an occasional blip won't take it down.
A few connectors don't support a test call at all and are skipped by the periodic health check.
Credential fields stay locked on an Active connection; use Disconnect first if you need to replace credentials you know are already invalid.