what shipped, when.

One password, shared. A private page now has two ways in, the emailed code and a page password, and either one lets a visitor in. The password suits readers an email list fits badly: people on personal addresses, a partner's NOC, a wall screen. Turn it on in the access tab, type one or press generate for a 20-character one, and copy it before you save. It is stored as a hash, so it can be replaced but never shown again.

Changing it shuts everyone out. Password visitors are anonymous, so there is nobody to block one by one. A new password, or turning it off, signs out every device that came in with it. Turning it off keeps it, and turning it on again brings the same one back. Sign them all out ends the open sessions and leaves the password as it is.

Guessing is slow. Ten wrong tries in 15 minutes from one network, then the sign-in screen says how long that network waits. The page itself never locks, so wrong tries from one place cannot keep everyone else out.

Subscribing. Someone signed in with the password subscribes by email and confirms the address first, as on a public page. Those subscriptions are marked via password and end when the password changes.

API, MCP and Terraform. access.password in the REST API sets the password (write only, never read back), and access.session_days now applies to both ways in. The MCP tools turn a stored password on or off but never take one. Provider 0.18.0 adds a write-only password to uptimepage_status_page and moves session_days to match.

Docs: who can open a page, status pages through the API, Terraform.

Status updates. A maintenance window now takes updates, like an incident: a reminder before it starts, a line when the work runs late, how it went once it ends. Post one from the window's new page in the console, through POST /api/v1/maintenance/{id}/updates, or with the MCP tool post_maintenance_update. The status page shows the newest one under the window, and email and webhook subscribers get each one (type maintenance_update). A completed window still takes updates, so you can add a closing note.

Maintenance days. On the 90-day strip, a day a window touched shows as maintenance, and time inside a window no longer counts against the uptime figure. An outage outside the window on the same day still counts. Hover over a maintenance day, or tap it, to open the window in the archive. A monitor added to a running window counts from when it was added, and one dropped from it counts until it was dropped.

Finished maintenance in the history. Ended windows now sit in the page history next to past incidents, newest first, with All, Incidents and Maintenance tabs on the page and in the 90-day archive. A row opens to the window's description and every update. The history section shows on a quiet page too, and always links the archive. GET /api/public/v1/maintenance/past lists ended windows, and /api/public/v1/status carries recent_maintenance.

A page keeps what it showed. An incident or a started window stays in the page history, under the name the page gave the monitor, when that monitor is removed from the page, deleted, or dropped from a running window.

Upcoming windows. The page lists windows up to 30 days ahead, and every window time names its zone.

Date and time picker. A window's start and end, and an on-call handoff, are now picked in the console's own date and time picker, with a 24-hour clock.

Updates post once. The update routes for incidents and for maintenance accept an Idempotency-Key, and the console sends one, so a retried or double-clicked update is posted once.

Docs: scheduling maintenance, status updates, what the page shows, idempotency. Guide: how to announce scheduled maintenance.

Private pages. A status page can be public, private or off. A private page opens only for the email addresses and domains on its access list: example.com lets in everyone at that domain, and an address lets in one person, up to 500 entries. Pick private under who can open it in the page editor and fill in the list on the new access tab. Private pages come with the Team plan, and with every self-hosted install.

Signing in. A visitor sees a sign-in screen in the page's branding and language, enters their email and gets a 6-character code and a sign-in link. Every address gets the same answer, so the screen never tells anyone who is on the list. After the first code, a viewer can save a passkey and skip the email next time. You choose how long a sign-in lasts (until sign-out, or 7, 30 or 90 days) and whether passkeys are offered.

Everything sits behind the sign-in. The page, the incident history and detail pages, the JSON API, the badge and the RSS feed answer only a signed-in viewer, and none of it is cached or indexed. A viewer's feed reader gets a personal link that stops working when they lose access.

Subscribers. Making a page private removes its webhook subscribers and the email subscribers the list does not cover. A signed-in viewer subscribes as themselves, with no confirmation mail.

Viewers. The access tab lists who signed in, when they last visited and their history for the past year. Block signs someone out at once and keeps them out whatever the list says.

API, MCP and Terraform. The access field of a status page sets the list and the sign-in options through the REST API and the MCP tools. Provider 0.16.0 adds an access block to uptimepage_status_page.

Off pages stay quiet. A page that is off no longer sends mail or webhook calls to its subscribers, and nothing is sent for an organization that was deleted.

Docs: who can open a page, status pages through the API, Terraform.

An exact record set. A DNS monitor used to pass when an answer contained a piece of text. It can now list every record the answer must hold, one per line, and goes down when a record is added, removed or changed: a stray MX, a dropped A record, an edited SPF line. Pick exact set under the answer match in the monitor form, or send expected_records through the API or the MCP tools. Up to 50 records.

How records compare. Order and repeats do not matter. Names compare without case or the trailing dot, and numbers and addresses by value, so 10 Mail.Example.com matches 10 mail.example.com. and 2001:0db8::1 matches 2001:db8::1. TXT and CAA values compare as written, case included. Write a record the way the result's answers show it, or in zone file form. A value the record type could never answer with is refused when you save, so a typo cannot leave a monitor down for good.

See what changed. When the set differs, the result lists the records that are missing and the ones that are unexpected. Answers now hold only the record type you asked for; a CNAME chain the resolver followed shows under aliases. A contains match still searches the chain, so existing monitors judge as before.

Underscore names. Names such as _dmarc.example.com, s1._domainkey.example.com and _sip._tcp.example.com were refused when you created the monitor. DNS monitors accept them now.

PTR on an IP address. A PTR monitor on an IP address sent a forward lookup and failed on every check. It now looks up the address's reverse name. The other record types refuse an IP address when you save, since they could never pass.

Terraform. Provider 0.15.0 adds expected_records to the dns block of uptimepage_target and accepts underscore names.

Docs: DNS monitors, DNS through the API, Terraform.

Duplicate a monitor. Pick duplicate in the menu on a monitor's row or page. Each copy runs with every setting of the source and gets its own name and, if you like, its own URL, host or domain. Paste a list of addresses into one box to add a row for each. Up to 100 copies go in one batch, and the batch is created entirely or not at all.

Everything carries over. The old copy filled in the create form in your browser, so it dropped credentials set through the API, the regions and the escalation policy. Duplicate copies the saved monitor instead: the check with its credentials, the interval, the paused or running state, tags, group, alert channels and regions. The escalation policy comes along when you could attach it yourself, as the org owner on a plan with on-call. You own the copies, and a heartbeat copy gets its own ping URL. History, incidents, status page components and share links stay with the source.

Through the API. POST /api/v1/targets/{id}/duplicate takes a list of copies, each with a name and an optional address. It counts against the bulk rate limit and accepts an Idempotency-Key header.

Also fixed.

• A retry with the same Idempotency-Key used to get the first answer back for 24 hours, even when that answer was a 429 or a 5xx. Only a success is kept now, so a retry gets a fresh answer.
• A bulk create with a very large response could create every monitor and then answer 500, inviting a retry that made each one twice. It now answers with the monitors.
• Creating a heartbeat could answer with an error after the monitor was saved, so a client or agent that retried got two. The create now succeeds whenever the monitor is saved.

Docs: duplicating through the API, idempotency.

Passkeys from password managers. Sign-in never asks for your address first, so it can only use a passkey kept on the authenticator itself. Registration asked for one without requiring it. Phones, laptops and security keys kept one anyway, but password managers that do exactly what they are asked, such as the Bitwarden browser extension, saved a kind sign-in cannot use, and adding the passkey failed. Registration now requires a passkey kept on the authenticator, so these password managers save one you can sign in with.

Left over from a failed try. A passkey from an attempt that failed never reached your account. Delete it from your password manager, then use add a passkey on your account page again.

Docs: passkeys.

System follows your OS. The new System theme shows the Dark theme when your operating system is set to dark, and the light Default look otherwise. It checks once per page load, so a chart never changes colour while you read it. Pick it, or any of the other 13 themes, under appearance on your account page.

Default moves to System. System is now the theme a new account starts on, unless you picked a mode on the website first. Accounts that were on Default have moved to it, so if your OS is dark, the app is dark now too. Pick Default again to keep the light look. Any other theme you chose stays as it was.

Native controls match. Dark themes now tell the browser they are dark, so scrollbars, date pickers and other native controls render dark instead of white. The Dark theme draws its accent buttons in white with dark text instead of pink. The legal pages on the app follow your theme too.

Pick before you sign up. The website has a light and dark switch in its header, or in its menu on a phone. Use it before you sign up and your new account starts in that mode: Default for light, Dark for dark. After that the switch changes only the website, never your account's theme.

Docs: the web UI.

Day colours follow downtime. A day on the 90-day strip used to take the colour of the worst thing that happened, so a four-minute blip painted it as red as a lost afternoon. The colour now follows how long the component was down, weighted the way Atlassian Statuspage weighs it: a partial outage counts for 30% of its length, and degraded performance does not count as downtime. Under 20 minutes reads yellow, 20 to 60 orange, an hour or more red. Hovering a day lists the time it spent in each state.

Uptime weighs downtime the same way. The uptime figures on the status page, the dashboard, the monitor list and page, the uptime API and the MCP tools now count a partial outage at 30% of its length and leave degraded performance out, so the number beside a strip agrees with its colours.

Past incidents fold. The past-incidents list was a card per incident, so a service that flapped for an hour filled the page. Incidents on one component less than an hour apart, and incidents on different components that began together, now fold into one row that opens to the incidents inside it. An incident you posted an update to keeps its own row with your words; the lines the platform writes for you are left out. The last week is open and older incidents sit behind one toggle. The archive lists each month the same way.

A recovery period for flapping monitors. A monitor can now wait out its recovery before its incident closes: set Close incident after in the monitor's detection settings, or recovery_period_secs through the API and MCP tools. A failure that confirms inside the window keeps the same incident open, so a service that keeps falling over is one incident and one set of alerts. The end is still dated to when the last recovery began, so the wait is not counted as downtime, and while it waits the monitor reads as back up: paging pauses, the status page shows it operational with the incident as Monitoring, and the console marks it recovering. If it falls over again inside the wait, the minutes it was back up still do not count as downtime. HTTP, TCP, ping, DNS and flow monitors, existing ones included, wait three minutes unless you pick another hold; choose at once to close as soon as the checks pass again. Heartbeat, manual and expiry monitors still close at once, since their next check can be hours away.

Recovery is judged per region. A region now counts as recovered only after as many passing checks in a row as it took failing ones to count as down, and a region that never failed is no longer evidence that the others recovered. A stray failed check no longer moves an incident's end.

Docs: public status page, incidents, API.

Each status page now has a language. English stays the default, and German is the first one added. Set it under Language in the page editor, or as public_locale on the page through the REST API.

What changes. Everything the page writes itself: status labels and headings, the subscribe dialog, dates and durations, the title of an incident you never named, the status badge, and the confirmation, incident and maintenance emails your subscribers get. A German page formats dates the German way in every browser and sends Content-Language: de.

What stays. Text you write appears as written: page, component and group names, the about text, incident titles and updates, and maintenance windows. Email times stay in UTC.

One language per page. A page with two audiences is two pages, each with its own subscribers.

Terraform. Provider 0.14.0 sets the page language with locale on uptimepage_status_page. Leave it out to choose the language in the console instead. Removing the line keeps the language it set, so set en to switch back.

Docs: public status page, per-org status pages, Terraform.

Some services can only be judged by the people running them: a SIP trunk, a carrier interconnect, a partner's back office. A manual monitor puts them on your status page next to everything else. It has no probe, and its state is whatever someone last set.

Set the state. A manual monitor starts up. Set it to up, degraded or down from the monitor page, with PUT /api/v1/targets/{id}/state, or with the MCP set_monitor_state tool. An optional note of one line, up to 200 characters, becomes the incident's cause, so write it for whoever gets paged.

Like any other monitor. Down or degraded opens an incident within about 30 seconds and pages its channels, unless a maintenance window holds paging. Status pages show a major outage or degraded performance, and up closes the incident. There is no confirmation count to wait out, because the person who set the state already confirmed it. Downtime counts against uptime, and the monitor counts toward your monitor limit.

Who and when. The monitor page shows when the current state was set and which member set it. Every change is recorded with who made it, and setting the same state with the same note again changes nothing. A manual monitor that is paused, or that your plan no longer covers, keeps the state you set and reports it once it runs again.

Access. Reading the state needs targets:read and setting it needs targets:write, so existing tokens and MCP connections with those scopes can use it now.

Terraform. Provider 0.13.0 declares one as check = { type = "manual" } on uptimepage_target, with interval = 60. The state is not configuration, so a set in the app never shows as drift.

For every monitor. An incident that opened as degraded is now raised to an outage once its monitor is confirmed down, so its status pages show an outage instead of degraded performance. It used to keep the impact it opened with.

Docs: manual monitors, REST API, MCP server, Terraform.

The MCP server can now manage maintenance windows, the same ones the console and the API schedule.

Read. list_maintenance lists windows by status (active, upcoming or past), and get_maintenance reads one, with the monitors it covers and whether it holds their paging.

Schedule. create_maintenance takes a title, a start and an end, and the monitors the work touches. Paging for those monitors is held while the window runs unless you turn that off, and the checks keep running, so it is the gentler choice than pausing a monitor. The confirmation names the monitors, says whether paging is held, and says which of them sit on a published status page, because that page's subscribers are told about the window.

Edit, end, cancel. update_maintenance changes an upcoming or running window and shows the old and new value of each field. Its end_now flag ends a running window at once. cancel_maintenance withdraws a window that has not ended and keeps it under past as a record. A completed window is history and is refused.

Access. The read tools need maintenance:read, now part of the read only grant. The write tools need maintenance:write or maintenance:delete, which come with the Manage monitors level on the consent screen. A connection keeps the scopes it was granted, so reconnect to add these.

Docs: MCP server, scheduling maintenance.

Maintenance windows used to be API only. The console now has a Maintenance page for them.

Schedule. Pick the monitors, a start and an end in your own timezone, and an optional description. Readers see the window on your status page, and subscribers get a notice when you schedule it and another when it ends. A monitor that is not on a status page is flagged in the picker, because readers cannot see it there.

Hold paging. On by default. A monitor inside a running window still opens incidents, but its channels stay quiet, and an incident still open when the window ends pages then. Turn it off to keep paging live. An incident you declare by hand always pages.

Edit, end, cancel. An upcoming window can be edited or cancelled. A running one can be edited or ended now. Cancelled windows stay under Past with who cancelled them and when, and every change is written to the organization audit log.

Quota. Only windows that have not ended count toward the limit. Completed and cancelled ones are history.

API: a PATCH that sets ends_at to now or earlier on a running window ends it at the server's clock, status=upcoming now lists the soonest first, and a window can no longer be created or edited to end in the past otherwise.

Docs: scheduling maintenance, REST API.

You can now acknowledge an incident from its chat and email alerts, and the incident shows who acknowledged it.

Who acknowledged. Any member can acknowledge, on call or not. The dashboard banner, the console and the incident page list who acknowledged, in order. The first keeps the credit: they stay the acknowledger on record, and their time is what MTTA measures. Once you have acknowledged in your own name, the button there goes away for you, and a reopened incident starts a new list.

From chat and email alerts. Slack, Discord, Microsoft Teams, Google Chat and email alerts carry an Acknowledge button, and Mattermost alerts end with an Acknowledge link. It opens the incident's acknowledge page, where you sign in and take it in your own name. Opening the page changes nothing, so a link preview or a mail scanner cannot acknowledge for you, and an alert from an earlier outage takes nothing once the incident has come back.

Inside Slack and Discord. A channel connected with add to Slack or add to Discord from now on carries an Acknowledge button that works in the chat itself. A press acknowledges at once. Until you link your Slack or Discord account, it is recorded as coming from Slack or Discord, and the reply, which only you see, brings a link: open it, sign in, and later presses carry your name. The chat also gets a reply under the alert naming who took it, without mentioning anyone. A channel whose webhook was pasted, or one connected before this change, keeps the page link.

Telegram and Pushover. A page from the Uptimepage Telegram bot now carries an Acknowledge button, and a Pushover emergency acknowledgement reports who took it. Link Telegram from your account settings. Pushover links itself: acknowledge an emergency page from an account nobody has linked, and it brings you a one-time link, at most once a week. A name is never guessed from where a page was sent, since a shared chat or a Pushover group reaches more than one person.

Turning the button off. Every channel that carries the button has an Acknowledge button switch, on by default. Turn it off for a room shared with a customer or an open ntfy topic, and the buttons already sent stop working too. The API takes it as acknowledge_button.

On a self-hosted install, the buttons inside Slack and Discord need your own Slack and Discord apps, and the Telegram button needs a central Telegram bot, each set up as the configuration docs describe. Without the Slack and Discord apps, those channels keep the page link.

Docs: acknowledging from the notification, the incident console, Slack and Discord app setup.

An incident on a monitor can now page whoever is on call. On the hosted service this is part of the Team plan, and a self-hosted install always has it.

Schedules. A schedule is one or more rotations, called layers. People hand off daily or weekly at the same local time, even across daylight saving, or on an interval you set. A layer can be on call at all hours or only in the hours you give it, such as Monday to Friday 09:00 to 17:00. The first layer on call at a moment is the one that pages, so working hours on one rotation and nights and weekends on another fit in one schedule.

Calendar and overrides. A saved schedule's page shows a calendar of who is on call each day. Click a start day and an end day, then pick who covers, to hand a holiday or a swap to someone else without touching the rotation.

Your shifts. Each person picks the channels that page them on the on-call page. Until they do, a page on their shift reaches no one, and the page says so. The same page lists their next shifts in the organization and offers a private link that Google Calendar, Apple Calendar or Outlook can subscribe to.

Escalation. A policy is a ladder of levels. Level 1 pages when an incident opens, and each level waits before the next one pages. A level can page notification channels, on-call schedules, or both. Bind a policy to a monitor, or make it the default for every monitor without its own. A monitor with a policy pages the policy's levels instead of its own channels, so put those channels on level 1 to keep them. Acknowledging or resolving the incident stops the escalation.

Docs: on-call schedules, paging and escalation.

Alert emails go out over a fresh connection. On the morning of 21 September about half of alert emails failed their first send and arrived minutes late on a retry; a handful were dropped after the retries ran out. The sends were reusing a connection to the mail provider that had gone dead. Every alert mail now opens a fresh connection, and a retry can no longer race a first attempt that is still in flight, so an alert is sent once.

Mail comes from hello@uptimepage.dev. Alerts, sign-in links and invitations used to come from a no-reply address. Replies to hello@ reach a person.

Pages with large headers are up again. A site that answers with more than 16 KiB of response headers, such as finance pages with long preload lists, was recorded as down with a "transport error" while it was serving fine. The probe now accepts up to 256 KiB of headers over HTTP/2 and 1024 header lines over HTTP/1.1. Sorry to everyone who was paged for a healthy site. A test check's header preview now cuts a value over 512 bytes, and a cut body snippet ends in "…".

Probe errors say what happened. A request the server dropped after the TLS handshake used to show a bare "transport error". The monitor, the API and the MCP server now say "server reset the connection before responding", "server closed the connection before responding", "server sent an invalid HTTP response", or the HTTP/2 reason the server gave. When the probe itself refuses a response, the error says so instead of blaming the server.

A new account's org gets its owner's email channel. A signup through a magic link got an org with no notification channel, so its monitors paged nobody until one was added by hand; GitHub and Google signups already had the owner's address seeded. Every org a sign-in opens now gets it. An org created from the console is unchanged: add a channel to it yourself.

Self-host. The [email] block is checked at boot: from_address must be a bare user@domain and is required under resend, provider must be resend or log, and a no-reply sender is warned about. A half-configured mail setup now refuses to start instead of failing on every send. See configuration.

One uptime number. The dashboard and the monitor page counted confirmed incident downtime; the monitors list counted failed checks. The same monitor read 99.99% on one screen and 99.76% on the next. The list now uses the confirmed figure too.

Status page uptime is time-based. It used to be days without an incident over days with data, so a four-minute outage in ten days of history read 90.00%. It now reads 99.97%: confirmed downtime over the time the component has been probed. uptime_pct is on the public API as well.

Status page cards use the strip's words. The history strip said "Partial outage" while the incident card said "Major". Cards now carry the measured impact (Degraded, Partial outage, Major outage) for monitor-opened incidents and the declared severity's impact for declared ones. The public API adds impact beside severity.

Subscribers hear the outage start. A monitor-opened incident on a status page posted only its closing update, so subscribers received one mail, "Resolved", after the fact. The writer now posts an opening update too, and the mail is titled the way the page titles the incident instead of "Status update".

Console. The dashboard incident count is labelled with the range you picked. The monitors list offers ping, heartbeat and flow in the type filter, its heading count follows the filters, and the URL it pushes survives a reload.

The edit form never offered it, but PATCH /api/v1/targets/{id} accepted a check of a different type: an http monitor rewritten as a heartbeat, or back. The monitor kept its id, so both kinds' results landed in one history and uptime was computed across them.

The API now refuses it with 400 CHECK_KIND_IMMUTABLE. Change any other field of the check freely; to watch something of another kind, create a new monitor. The same rule holds at the database row, so no other writer can slip past it.

If you manage monitors with the Terraform provider, version 0.12.0 plans a type change as a replacement: the old monitor is destroyed and a new one created. Older provider versions fail at apply.

Docs: REST API.

Heartbeat monitors. Heartbeats created through the first version of the form were judged hours apart, so a missed ping was noticed late and a manual resolve reopened the same outage. Existing intervals were corrected to a tenth of the window, between one and five minutes, and the API now refuses a coarser one. If you have heartbeats, they page faster now.

Telegram supergroups. When a group is upgraded to a supergroup, Telegram gives it a new chat id and the old one dies. The channel now follows the move on the first failed send and saves the new id. Bring-your-own bots are covered too.

Incident region breakdown. With majority quorum the last region is usually one check behind when the incident opens, and alerts named it under "up". It is now "not confirmed", and the breakdown widens as regions confirm instead of staying frozen at the snapshot taken at open.

Self-host. A region can be opted out of new monitors' defaults with regions.default_selected. It stays pickable on the form, just starts unchecked. See multi-region probes.

The MCP server now covers the setup path, not just reads. 16 read tools and 15 write tools, every write behind a confirmation in the client.

• create_status_page, update_status_page, add_status_page_components and update_status_page_component. Owner-gated, same bar as the REST API.
• create_monitors puts a batch behind one confirmation instead of one prompt per monitor.
• HTTP checks take request headers and a body. A credential is referenced as Bearer {{ key }} from your org variables, never pasted. A pasted literal is refused.
• Monitor create takes regions and binds notification channels, so a monitor made from a client pages someone from the first check.
• get_org_usage tells you which org the token is bound to. Scope and org refusals say how to rebind.

One setup page per client, each with the exact config for that client: Claude, Cursor, VS Code, Grok. Hub: /mcp-server.

Reference: MCP server docs.

Three small status page controls.

Hide from search engines. The page, its incidents and the archive carry noindex. The URL keeps working for anyone who has it. For a page you share with customers by link but do not want indexed.

Header link. With a website set, the logo or display name in the header links to your own site, so a reader has a way back other than the browser button. Every plan gets the link; on hosted it carries rel="nofollow" unless the plan includes white-label, so an open signup cannot be farmed for backlinks.

Powered-by toggle is in the page editor. It used to be API-only, and saving the editor cleared it. Honoured on plans with white-label; elsewhere the badge always shows.

Also fixed: a grouped page now keeps the component order you dragged it into.

Docs: public status page.

Two new notification channels.

Mattermost. Incoming webhook, works on Mattermost Cloud or your own server. Mentions use the server's own username rules, so directory-synced handles like svc.oncall.emea work.

Gotify. Point a channel at your Gotify server with an application token. Priority follows the client scale: 8 for a high-urgency open, 5 for other opens, 3 for a resolve. The incident link is the notification's click URL.

Acknowledging from the notification itself. An ntfy page carries an Acknowledge button, and acknowledging a Pushover emergency page in the Pushover app acknowledges the incident here too. That stops the repeats still going out on other channels. The link is signed, expires after a week, and is tied to the exact episode it was sent for, so a stale alert on a phone cannot silence a later outage.

Docs: notifications.

No account needed, no email capture.

• SSL certificate checker: chain, issuer, expiry, days left.
• Domain expiry checker: registrar expiry for the domain, the thing that takes a site down with no warning.
• HTTP header and redirect chain checker: every hop with its raw Location, the final status, and the full header set. Names the failures the last status code hides: a loop, a hop limit, a chain that leaves the host and drops cookies, a chain ending on plain HTTP.

All tools: /tools.

Until now there was no way to create a second organization in the app. The API existed, the button did not.

/settings/organizations covers create, rename, delete and restore. /settings/team is only about people.

• Deleting an org asks you to type its name back.
• A deleted org's slug is held for the whole restore window, so nobody can grab it in between.
• If an org blocks your account deletion because you are its only owner, you can hand it a second owner instead of deleting it.
• Sessions pointed at a deleted org are moved, not stranded on a login loop.

Docs: organizations.