When your org is suspended

If your org is in a suspended state, Upwarden blocks new proxy traffic and freezes dashboard mutations until it’s reactivated. This page walks through what members see, what’s blocked vs. what still works, and the recovery path.

Suspensions are issued by Upwarden staff (super-admin only). They’re not self-serve — there’s no panel in your dashboard to suspend your own org, and there’s no automatic suspension triggered by usage caps. If your org has been suspended, you’ll have received an email from Upwarden support with the reason.

What you’ll see in the dashboard

When a suspended-org member signs in, every authenticated page in your org carries a red banner at the top:

This organisation is suspended. Proxy traffic is blocked and dashboard mutations are disabled. Contact support@upwarden.io to reactivate.

If the suspending operator typed a reason, the banner appends Reason: <text> so you have the immediate context without checking email.

The banner sits above the page header on every authenticated route — overview, audit log, packages search, settings, members — so you can’t miss it after sign-in. You stay signed in (your sessions are not destroyed) but the dashboard becomes effectively read-only:

• Reads stay open. You can navigate the dashboard, read the audit log, inspect package verdicts, review members, and read your settings — exactly as before.
• Mutations 403. Every POST / PUT / PATCH / DELETE under /admin/ui/orgs/<slug>/* returns a 403 with a tenant_suspended envelope. The dashboard surfaces a flash banner on the redirected page; the JSON admin API surfaces the same envelope verbatim in the response body.

The single exception is your own account surface (/admin/ui/me/* — profile, sessions, passkeys). That lives outside the org scope and stays fully writable so you can rotate a passkey or sign out a stolen session even while your org is suspended.

What stops working

Proxy data plane

Every package-install request from your CI runners against <eco>.pkg.upwarden.io is rejected with HTTP 403 and the body:

[UPWARDEN] Org is suspended — contact support@upwarden.io to reactivate.

(Plain text, terminating newline — your package manager’s stderr will surface it verbatim.) The 403 fires before the scan-usage counter increments, so a suspension does not run up your monthly count.

If your CI doesn’t fail-loud on an Upwarden 403, you’ll see installs falling back to whatever your manager does on registry errors — typically a build break with the [UPWARDEN] line in the logs, or an EAI_AGAIN / 404-style timeout once retry budget is exhausted. The [UPWARDEN] prefix is your signal that the cause is Upwarden, not your registry.

Admin JSON API mutations

A mutating call against /api/v1/admin/orgs/<slug>/* (rotating a key, editing policy, inviting a member, posting an allowlist rule) returns:

{
  "error": "tenant_suspended",
  "message": "Org is suspended — contact support@upwarden.io to reactivate."
}

Status is 403. The error code (tenant_suspended) is stable — if you have automation that retries on transient failures, key off the code and exit cleanly rather than retrying.

GET-shaped admin reads (listing members, fetching a key by id, reading policy) keep working — same posture as the dashboard.

Webhooks

Inbound /triggers/webhook deliveries (the customer-side triggers webhook that lets you fan an event into Upwarden) are rejected with the same tenant_suspended envelope. Outbound webhooks (the events Upwarden fires to your subscribers, e.g. org_renamed) are paused — the queue keeps the events, but the dispatcher doesn’t fan them out until the org is reactivated.

What still works

• Reading the dashboard. Every page is open. Use this time to audit the org — read the audit log, confirm your members are who they should be, and review recent policy changes.
• Your own profile. /admin/ui/me/* is org-agnostic and stays writable. Passkeys, recovery codes, signing other sessions out — all fine.
• Sign-in. New sign-ins by existing members succeed. The banner explains the state. New members cannot be invited (that’s a mutation) and JIT auto-join is blocked, so even an SSO-trusted user signing in for the first time will not provision into a suspended org.
• Audit log retention. Suspension does not change retention. Whatever your tier’s audit_retention_days window is (see Policy overrides) keeps running. If you suspect the suspension itself is the issue, the org_suspended audit row carries the operator id and the optional reason text — that’s the canonical record.

What’s unchanged about your billing

A suspension freezes the data plane, not your subscription:

• Seat count. Suspended-status members are still seated. The seat cap does not drop while suspended.
• Monthly subscription charge. Unaffected — the cycle continues normally.
• Tier. Your tier (Free / Team / Org / Enterprise) does not change. When you’re reactivated, every tier-gated feature returns to the same posture it had before.
• Scan usage. The monthly scan count is paused — every proxy request 403s before the counter touches it. If you reactivate mid-month, the count resumes from where it left off.

If suspension is being used as a billing lever (e.g. payment failure), the reason the banner surfaces will say so, and the recovery path is “resolve the billing issue, then ask support to reactivate”.

How to recover

The reactivation path is admin-only — operators at Upwarden flip the state column back to active. There’s no self-serve unsuspend in the dashboard or the admin API.

1. Email support@upwarden.io. Reference your org slug. If you have an open ticket number from the suspension email, reply on that thread — it’s faster than opening a new one.
2. Resolve the cause. If the suspension reason was billing, settle the invoice. If it was an abuse / policy concern, work with the support team on the remediation step. The banner’s Reason: line is your single source of truth for what Upwarden needs from you.
3. Wait for the reactivation confirmation. When the operator unsuspends, an org_unsuspended audit row writes (visible in your dashboard the moment the state flips). The banner disappears on the next page navigation. Every member’s session-revoke is symmetric: existing sessions are not destroyed on unsuspend, so you’ll generally not need to sign back in.

Auditing a past suspension

Three audit envelope shapes write across the lifecycle. Filter the audit log by event string to pull the timeline:

Event	When it fires	Carries
org_suspended	At the moment the operator flips state → suspended	{tenant_slug, by_user_id, reason, member_count, revoked_count}
org_suspended_request_blocked	On every 403 from a suspended-org request (proxy or admin)	{tenant_slug, route}
org_unsuspended	At reactivation	{tenant_slug, by_user_id}

For a one-screen view: pivot the audit log by event_string and filter to those three values. The org_suspended_request_blocked rows are noisy (one per blocked request) but useful for “how much CI traffic did this suspension cost us” calculations. The by_user_id field on the two state-flip events identifies the Upwarden operator who acted.

What’s next

• Querying the audit log — the JSON-API patterns for pulling the suspension audit envelope.
• Troubleshooting — generic “why is my install blocked” flowchart. A suspended-org 403 is one of the entries.
• Policy overrides — the related tightening surfaces; some of the same governance posture applies.