> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automatedoperations.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reconnect an integration

> What the needs reconnect label means, who can reconnect PagerDuty, Linear, GitLab and Datadog installs, what is kept, and what to do when the sign-in is for a different account.

When an integration shows **needs reconnect** on the **Integrations** page,
the provider has stopped accepting the sign-in AO saved for it. The provider
keeps refusing that sign-in, so the label stays until someone signs
in again. Reconnecting takes one sign-in and fixes the same install in place.

## What the label means

A provider can refuse AO's saved sign-in for several reasons, and none of
them means anyone did something wrong. For example:

* Access for AO was removed in the provider's settings.
* The person who connected the integration left, or lost access.
* The provider ended the authorization on its side.

The card says which provider rejected the sign-in and shows a **Reconnect**
button.

## Who can reconnect

You need both of these:

1. **An AO role.** Only an Owner or Admin of your organization can reconnect.
   Other members see the card message but not the button.
2. **The right account at the provider.** AO checks that the sign-in belongs
   to the same account the install was made with:

| Provider | Who can reconnect |
| - | - |
| PagerDuty | Anyone in the same PagerDuty account |
| Linear | Anyone in the same Linear workspace |
| Datadog | Anyone in the same Datadog organization and site |
| GitLab | Only the same GitLab user who set up the connection |

After a teammate reconnects PagerDuty, AO uses **that teammate's** PagerDuty
access from then on. Pick someone who can see the same services you want AO
to follow.

## Reconnect

1. Open **Integrations** and find the card marked **needs reconnect**.
2. Choose **Reconnect** and sign in at the provider.
3. Approve access. AO returns to the Integrations page and the label clears.

## What is kept

Reconnecting repairs the existing install. Its name, webhook subscriptions
and history stay as they were. It does not count as a new install, so your
organization's install limit does not apply.

## What stops updating while it is broken

While an install needs reconnect, the provider refuses AO's calls.
For PagerDuty that means AO stops refreshing services, team ownership and
the primary on-call. They update again once you reconnect.

This page does not say whether PagerDuty keeps sending incident webhooks to
AO in the meantime: PagerDuty's documentation does not state it. Reconnect
promptly rather than relying on it.

## "That sign-in is for a different account"

AO refused the sign-in and changed nothing, because it belongs to a different
account than the install. Sign in to the account the install uses and try
again. If your browser is already signed in to the provider as someone else,
sign out there first.

## GitLab: the person who connected has left

Only the GitLab user who set up the connection can reconnect it. If that
person has left:

1. On **Integrations**, revoke the GitLab connection.
2. Install GitLab again and pick the groups and projects again.
3. Remove the old webhooks in GitLab under **Settings > Webhooks** for each
   group or project. AO cannot delete them, because GitLab rejects its saved
   sign-in.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.