Connector Outages

A connector outage is the platform refusing your project's live installation: the token was revoked or regenerated, or the bot was deleted. It is not a rate limit, not a passing API error, and not you pressing Disconnect; those never open one. Subscriby's health probe, hourly on every plan and every 15 minutes on Growth, notices the refusal, records the installation as Degraded with the reason, opens a Disaster Recovery incident and, from this release, an outage. The probe's cadence is also the most an outage can run unnoticed, which is why the pricing page states it beside the Disaster Recovery Program on every plan.

While the outage runs

• Sales freeze. Every plan that unlocks a place on that connector is taken off sale everywhere at once: the portal shows Temporarily Unavailable on the card, the bot refuses the plan, access codes and free trials for it are refused, and the REST checkout answers with a validation error. Plans that hand out perks only stay on sale, because there is nothing there the connector has to deliver.
• Existing members keep what they have. Nobody is removed from a channel or group during an outage; the connector cannot act, so expiries wait.
• The dashboard says so. The project's Connectors page badges the installation Sales Paused, the Disaster Recovery page shows an amber Connector outage callout naming the project, the connector and when it began, and the installation object on the Connectors API reads sales_paused: true with an outage block.
• Integrations hear it. connector.outage_opened fires once when the outage begins.

When it ends

An outage ends when the probe finds the installation healthy again, when you reconnect it, when another bot takes its place (a standby bot through automatic failover, or one you relinked yourself), or when you uninstall the connector. connector.outage_closed fires with how long it ran and how it ended, the plans return to sale, and the settlement below runs from the queue.

Outage Compensation

Every project carries an Outage Compensation switch in its settings, on by default. While it is on, an outage that lasted an hour or more and ended because the connector recovered or was replaced compensates every affected member: each purchase that grants access right now and unlocks a place on that connector has the outage's length banked on it, so nobody pays for hours they could not use. Passes and series are left alone, because a dated window cannot move, and so are plans that hand out perks only. An outage shorter than an hour, roughly the gap between two probes, is treated as a blip and earns nothing.

Why the time is banked rather than billed

No payment provider lets a renewal move by a few hours: Stripe, PayPal, Paystack, Razorpay and the rest bill on their own schedule and rewrite the period end on every sync. Subscriby therefore never touches a charge, a refund or a renewal date. It banks the seconds on the purchase and adds them back on top of every period end a gateway reports, so the time survives every renewal. Where the member feels it depends on how the plan bills:

• One-time and lifetime-style purchases end later at once: the end date moves by the outage's length.
• Recurring plans keep their renewal date and charges exactly as they were. The member's access always runs the banked time past the period they last paid for, and they receive it when the membership ends, whether they cancel, let it lapse or a renewal fails.

A member who lives through two outages banks both; the total is compensation_seconds on the subscription object, and ends_at already includes it.

Who hears what

• Members are told twice, in the chat their connector binds to them and by email, in plain words and without naming the platform or the cause: a fixed-term purchase is told its new end date, a recurring one that the time waits at the end of the membership. The same line then sits on their portal membership card and in the bot's subscription screen, for example Outage credit: 3 hours added to the end of your membership, and the portal keeps showing the real renewal date rather than the extended end.
• You receive one summary per outage, by email and on your connected account, and in the notification centre: how long the connector refused the installation, how many members received how much, and how many invites that never reached a member during the outage were re-sent. Nothing is sent when there was nothing to do.
• Your dashboard marks each compensated purchase with a Compensated badge in the subscriptions list, spells the credit out in its details, and lists every outage on the Recovery History page with how long it ran, how it ended and its Compensation column.
• Integrations hear member.access_extended once per member, saying whether the time applies now or at membership_end, then connector.outage_compensated once with the totals.

Switch it off if you would rather settle outages yourself, for example with refunds or coupons. The switch is also outage_compensations on the Projects API and the update_project tool.

Related

• How detection works — the probes behind the verdict.
• Replacing a banned bot — relinking, and the standby bot.
• What members see — the member's side of an incident.