RB-006 — JIRA site deactivated (Free plan auto-upgrade → unpaid Standard)¶

Use this runbook when: jira.448.global (Atlassian Cloud site) is inaccessible to all users with a "site deactivated" / "subscription suspended" / "no payment method" message, OR Atlassian has emailed warning of an imminent deactivation, OR the watcher described in KI-047 has fired.

id: RB-006
title: JIRA site deactivated after silent Free → Standard auto-upgrade
severity: high
estimated_duration: 30 minutes (if admin reachable) to several hours (support queue)
servers_affected: []           # Atlassian Cloud (SaaS), not our infra
apps_affected: ["JIRA"]
related_kis: [KI-047, KI-044]
related_actions: []

Trigger / detection¶

Any one of:

Users report jira.448.global returns an Atlassian-hosted "your site has been deactivated" / "subscription cancelled" page.
The n8n watcher (KI-047 mitigation step 1) has paged: user count ≥ 9 or plan tier ≠ Free.
An Atlassian billing email to the admin mailbox (today connect@448.global) warns of an imminent charge or deactivation.

If users can reach JIRA but see "project unavailable" or sudden permission errors, this is not this runbook — likely a permissions or licence issue per-project, not a site-wide deactivation.

Severity¶

High. When deactivated, all JIRA projects are inaccessible to all users:

Parallax dev + bug tracker (paying-customer UR work)
TnE Connect dev + bug, both Fourway (paying customer) and Eidos tenants
Other application boards

Engineering work across the paying-customer portfolio halts until the site is restored. Atlassian retains data on deactivated sites for a finite window (per their docs, typically ~15 days) — beyond that, data may be purged. Time matters.

What actually happened on 22 May 2026 (the precedent)¶

The user count crossed 10 (Stacy + Bhaumik added). Atlassian's billing flow silently upgraded the site from Free to Standard, attempted to charge, found no card on file, and deactivated the site. Recovery required:

Contacting Atlassian support.
Removing 2 users to drop back under 10.
Asking support to revert the site from Standard back to Free.

That sequence is the canonical recovery path. Do not improvise around it.

Required access¶

Atlassian organisation admin rights on the 448 Global / Project Eidos organisation. Today the primary admin is Adam Pitt-Stanley.
Access to the OTP mailbox for the admin account — today this is connect@448.global (Adam holds; see KI-047 for the OTP-relocation work).
Ability to contact Atlassian support: https://support.atlassian.com/contact/ (sign in with the admin account; the "billing & subscriptions" category gets the right queue).
List of current JIRA users sorted by last-active (to choose who to remove). Pull from https://admin.atlassian.com/ → Directory → Users; or via the API (see step 3).

Preconditions¶

Item	Status today
Admin login works	Requires `connect@448.global` OTP — bottlenecked on Adam
Card-on-file with spend cap (would prevent deactivation entirely)	Not in place — leadership decision pending, see KI-047 step 4
n8n watcher on user count / plan tier	Not in place — KI-047 mitigation step 1
Migration off Free plan (Standard paid, or self-hosted alternative)	Not decided — KI-047 step 5

Recovery steps¶

Step 1 — Confirm the failure mode¶

Open https://jira.448.global in a private window. Confirm the Atlassian-hosted deactivation page (not a Caddy 502, not a DNS failure). If it is a 502 / DNS failure, this is not the right runbook — jira.448.global is a Caddy reverse-proxy hostname on O1 fronting Atlassian Cloud; check Caddy (RB-001) first.

Also check the admin mailbox for any Atlassian email naming the cause (failed payment, plan downgrade, etc.) — the wording often points directly at the right remediation.

Step 2 — Reach an organisation admin¶

In priority order:

Adam Pitt-Stanley — primary admin, holds connect@448.global OTP.
Stacy Carpenter — co-owner; may hold org-admin role.
Atlassian support can verify ownership via the account-recovery flow if no admin is reachable, but this adds hours.

If Adam is reachable, obtain a fresh OTP from connect@448.global and log in to https://admin.atlassian.com/.

Step 3 — Identify users to remove (drop count to ≤ 10)¶

The goal is 9 active users after pruning, leaving one slot of headroom so the next add doesn't immediately re-trigger the auto-upgrade.

In admin.atlassian.com → Directory → Users, sort by Last active. Candidates for removal, in order of preference:

Inactive ≥ 60 days — safest removals; they aren't using JIRA anyway.
Recently-added users who haven't started using JIRA — often the trigger (this is what happened 22 May with Stacy and Bhaumik).
Users with read-only / occasional needs — can be re-added when actually needed.

Do not remove:

The org admin account itself.
The Atlassian service account used by n8n (see KI-044); removing it breaks the APEX bug reporter, CI/CD JIRA hand-off, and Parallax access-request flow.
Any user actively assigned tickets that are in flight on a paying-customer project.

Document the removal: who, when, why, and how to re-add them once the site is back and the longer-term decision (step 6) is made.

Step 4 — Contact Atlassian support¶

Open a ticket at https://support.atlassian.com/contact/ while signed in as the admin. Suggested template (this wording worked 22 May 2026):

Subject: Site deactivated after unintended Free → Standard auto-upgrade (no card on file)

Our Atlassian Cloud site jira.448.global was deactivated on <DATE> after the user count crossed 10, triggering an automatic upgrade from Free to Standard. We do not have a payment method on file and did not intend to upgrade. We have now removed <N> users so we are under the 10-user Free-plan limit.

Please: 1. Reactivate the site, and 2. Revert the subscription from Standard back to the Free plan.

Cloud ID / site URL: https://<your-site>.atlassian.net (and the vanity hostname https://jira.448.global).

This is blocking engineering across multiple paying-customer projects (Parallax for UR; TnE Connect for Fourway). Any acceleration appreciated.

Atlassian's billing team is the right team; chat or web ticket both work. Do not try to "rescue" the site by adding a card mid-incident unless leadership has approved the per-user spend — once on Standard with a card, removing it later is a separate fight.

Step 5 — Verify the site is back¶

Once support confirms reactivation and plan reversion:

Sign in to jira.448.global as the admin; confirm all projects are listed.
Spot-check one ticket in each major project (Parallax bug, Parallax dev, TnE Fourway bug, TnE Eidos bug) — confirm it loads with comments and attachments.
From the n8n side, trigger one JIRA-writing workflow (or watch for the next natural trigger) and confirm a ticket is created — validates the KI-044 service-account / Adam-token path is still functional.

Step 6 — Communicate¶

Tell the affected teams (Parallax engineering, TnE Connect engineering, anyone with open tickets) that the site is back. Note the half-day-class outage window in any client-facing SLA tracking.

Step 7 — Same-day hardening¶

To prevent immediate recurrence:

Lock the active user count to ≤ 9. Communicate to anyone with admin rights: do not add a user without first checking the count.
Stand up the n8n watcher if not already in place — KI-047 step 1. Until that lands, set a calendar reminder to manually re-check admin.atlassian.com → Directory weekly.
Escalate the leadership decision (KI-047 step 5): pay for Standard, self-host alternative, or stay on Free with watcher + this runbook. The second deactivation is no longer a near-miss.

Verification (post-recovery)¶

jira.448.global loads the dashboard for a logged-in user
Project list shows every expected project (Parallax dev + bug, TnE Connect Fourway dev + bug, TnE Connect Eidos dev + bug, others)
One ticket per major project opens with full history
An n8n JIRA-writing workflow runs successfully end-to-end
Active user count in admin.atlassian.com → Directory is ≤ 9
Plan in admin.atlassian.com → Billing shows Free
Removals from step 3 are documented (who, when, why, re-add plan)

Rollback / abort¶

There is no destructive action in this runbook — every step is either a removal that can be undone (re-add the user) or a support request that Atlassian executes. If support refuses to revert to Free, escalate to leadership (KI-047 step 5) rather than improvising; the wrong move is to add an unbudgeted card under outage pressure.

What to do if Adam (admin / OTP holder) is unreachable¶

This is the bottleneck called out in KI-047. Until the OTP destination is moved off connect@448.global and a second org admin is named:

Try Stacy Carpenter (co-owner) — she may already hold org-admin and not realise it; ask her to attempt sign-in.
If no admin can authenticate, file an account-recovery request with Atlassian support citing org ownership; provide whatever ownership proof they request (domain control of 448.global, billing-history references, etc.). This adds hours to days.
Meanwhile, treat the site as down and route engineering work to fallback channels (Teams threads, GitLab Issues on git.projecteidos.com). Do not let work disperse permanently — when JIRA returns, the unstructured work needs to be reconciled back in.

Post-incident¶

File at infra/incidents/YYYY-MM-DD-jira-deactivation.md:

Trigger: who was added, what time the upgrade fired, what time the deactivation hit.
Detection lag: how long from deactivation to someone noticing (target after the watcher lands: < 15 minutes; on 22 May it was hours).
Support-ticket reference and the wording that worked.
Which users were removed and the plan to re-add them.
Whether KI-047 mitigation steps have moved since the last incident.

KI-047 — the underlying risk; mitigation plan and strategic options.
KI-044 — Atlassian API token / service account; the watcher reuses this credential path.
KI-022 — alerting plumbing; the watcher is only useful if Gotify / email delivery works.
apps/25-n8n.md — n8n; where the watcher workflow lives.