---
title: "Automatic failover switched a project onto its standby bot without the creator, because the platform refused the live one: the bot-side twin of `recovery.resource_failed_over`."
method: POST
path: "recovery.installation_failed_over"
tags: ["recovery.* events"]
---

# Automatic failover switched a project onto its standby bot without the creator, because the platform refused the live one: the bot-side twin of \`recovery.resource_failed_over\`.

`POST recovery.installation_failed_over` (webhook)

### When this fires

A probe finds the platform refusing a project's live installation outright (the token revoked or regenerated, the bot deleted), the project has **Automatic Failover** switched on, a standby bot is registered and its last probe found it healthy, and the Project Bot allowance permits: the platform writes the standby's credentials into the project's installation, resolves the incident, closes the [connector outage](https://docs.subscriby.net/disaster-recovery/connector-outages) as `replaced`, and emails every member reachable by email their new link on the creator's behalf, at the per-email fee accepted when the switch was armed. This event fires the moment the switch completes; it sits under a recovery whose `recovery.operation_started` carries `automatic: true`, and the Project Bot allowance is spent exactly as by a manual relink.

> The switch cannot be undone from the dashboard: the refused bot is gone as far as the platform is concerned. The standby slot is empty afterwards, so the creator is asked to register a new standby bot.

### Caveats

- Fires only for a platform-caused refusal. A rate limit or a passing API error marks the installation degraded but never triggers a failover.
- When a condition fails (plan lapsed, no healthy standby, allowance spent, or the switch refused), nothing fires here; the creator receives *Automatic failover did not run for <project>'s bot* by email and on their connected account, and the incident stays open.

### Related events

- `recovery.resource_failed_over`: the channel-side twin.
- `recovery.operation_started` / `recovery.operation_completed`: the recovery around the switch.
- `connector.outage_closed`: the outage this switch ends as `replaced`.

## Headers

- `SB-Signature` string, required
- `SB-Event-Id` string, required
- `SB-Event-Name` string, required
- `Content-Type` string, required
- `User-Agent` string, required

## Payload

- object: The envelope every event is delivered in.
  - `id` string, required: A ULID unique to the event, prefixed `evt_`. Every retry carries the same id, so it is the key to deduplicate on.
  - `type` 'recovery.installation_failed_over', required: The event name, always `recovery.installation_failed_over` here.
  - `created_at` string, date-time, required: When the event was emitted, server time, ISO 8601.
  - `api_version` string, required: The contract version of the payload shape, `2026-05-01` today. A breaking change to a shape ships under a new version.
  - `project_id` string, uuid, nullable, required: The project the event belongs to; null for team-scoped and billing events.
  - `data` object, required: The event-specific payload. Keys that do not apply to a given emission are omitted rather than sent as null, so check for presence.
    - `connector` string, required: The connector the installations live on.
    - `installation_id` string, uuid, required: The project's live installation, now carrying the standby's credentials; the same row as before.
    - `members_emailed` integer, required: How many members were emailed their new link; `0` when nobody had a verified or billing address.
    - `operation_id` string, uuid, required: The recovery the switch ran under, marked automatic.
    - `project_id` string, uuid, required: Mirrors top-level `project_id`.
    - `replaced_at` string, date-time, required: When the switch completed, as recorded in the ledger.

## Acknowledgement `2XX`

Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.

## Other responses

- `default`: Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or `POST /v1/webhook-deliveries/{delivery}/retry`. After 20 consecutive failures the endpoint is paused until it is resumed.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)