> ## Documentation Index > Fetch the complete documentation index at: https://docs.cognee.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workspace Lifecycle > How a hosted workspace sleeps and wakes, and what happens to one that stays idle A hosted workspace is not running all the time. One that has been quiet scales to zero, and one that stays quiet for much longer eventually becomes a candidate for removal. **Nothing is destroyed in one step**: a workspace sleeps, is warned and marked visibly, and only then is anything deleted. Every stage before the last is reversible. | State | What it means | Reversible | | - | - | - | | Running | Serving requests. | — | | Asleep | Scaled to zero. All data intact. | Yes — opening it wakes it. | | Marked for deletion | Members have been emailed. Nothing is torn down yet. | Yes — contact support before the grace period ends. | | Deleted | Everything destroyed. | No. | ## Sleep and wake A hosted workspace that has been quiet for a while scales to zero — it goes to sleep. Nothing is lost while it sleeps, and you do not have to do anything to bring it back: opening it wakes it. While it starts, the app shows a **Waking {workspace}** screen in place of the [Overview](/cognee-cloud/ui/dashboard): *It went to sleep after a quiet spell. Starting it back up usually takes under a minute, and nothing was lost.* A **RESTORING · m:ss** counter under the message tracks how long it has been going, and keeps counting across a reload or a route change rather than restarting. After about **75 seconds** the message changes to *Still waking up. This one is taking longer than usual, but your data is safe.* A few details worth knowing: * **Every way in wakes it.** Switching workspaces in the picker, reloading the page, and opening a direct URL all go through the same wake, and the wake survives a reload rather than treating a still-cold workspace as an ordinary reconnect. * **A workspace that falls asleep mid-session is caught.** If it goes to sleep while your tab is open, the next request notices, wakes it, and retries once it is serving. * **The wait is bounded.** A workspace that never comes back lands on an error within minutes rather than spinning forever: **{workspace} didn't wake up** — *It was asleep and we asked it to start, but it hasn't come online. Try again, or sign out and back in.* * **The workspace badge says which state it is in.** A dashed, hollow badge means not running; its accessible label reads *running*, *asleep*, *waking up*, or *no active subscription*. In the workspace picker each row spells it out under the name — **Asleep · wakes when you open it**, **Waking up…**, **Didn't wake up**, or **No active subscription**. * **Not every page takes over the screen.** The full **Waking {workspace}** screen replaces the content of the Overview and of every page that reads from the workspace: [Datasets](/cognee-cloud/ui/datasets), [Search](/cognee-cloud/ui/search), [Skills](/cognee-cloud/ui/skills), [Graph](/cognee-cloud/ui/knowledge-graph), [Sessions](/cognee-cloud/ui/sessions), [Analytics](/cognee-cloud/ui/analytics), [Activity](/cognee-cloud/ui/activity), and the [Graph Model editor](/cognee-cloud/ui/datasets#graph-model-editor). Pages that do not touch the workspace stay usable while it starts — [Memory Coverage](/cognee-cloud/ui/memory-coverage) is one of them, and shows only the provisioning banner. A fetch that fails just after a wake names that as the likely cause rather than reporting a flat error: [Activity](/cognee-cloud/ui/activity) and [Analytics](/cognee-cloud/ui/analytics) both read *Couldn't load activity. If the workspace was asleep it may still be starting up; otherwise the activity endpoint is not answering.* Sleep applies to hosted workspaces only. The [local UI](/cognee-cloud/local-ui) runs for as long as your own process does. ## When a workspace goes to sleep On Cognee Cloud, a workspace is put to sleep once it has been idle for **3 days**, and the sweep that does it runs every two hours — so a workspace crossing that line is caught within a couple of hours rather than a day later. Members are emailed when it happens. Two things about this are deliberate: * **It is purely about idleness.** A paid workspace is not exempt: sleeping is reversible and costs nothing to undo, so an idle workspace of any kind scales to zero rather than burning compute. * **Nothing is deleted or moved.** The database, the files, the graph, the members, and the API keys are all exactly as you left them; only the compute stops. Anything that reads from the workspace wakes it — opening it in the app, switching to it in the workspace picker, or any authenticated API call. A request without credentials does not wake it, and neither do health or documentation probes, so a passing scanner cannot keep a workspace running. A woken workspace is typically serving again in well under a minute. ## If a workspace stays idle Sleeping indefinitely is not free — the storage behind a workspace still costs something — so the lifecycle continues past sleep: Members of a workspace that has slept for a long time are emailed a warning before anything is marked. The email says how many days remain until the workspace would actually be destroyed, not until it is marked. The workspace is flagged for removal. **Nothing is torn down at this point** — the data is still there and the state is visible on the workspace. What changes is that it no longer wakes on its own: getting it back is a support action, not a self-service one. After the grace period, the workspace and everything in it is destroyed: the database, stored files, memberships, and API keys. This step cannot be undone from the product. Two guarantees hold across this path: * **A workspace whose members were never successfully warned never becomes deletable.** The clock runs from when members were actually told, so a late notice does not shorten anyone's grace period. * **Workspaces with credit purchases or a saved payment method are excluded from the final step.** A workspace that has ever bought token credits — or whose owner has — or that has a saved payment method is never destroyed by this path, because a prepaid balance is held against the workspace. Buying credits during the grace period rescues it. Today the automatic removal stages are **not enabled on Cognee Cloud production**: hosted workspaces sleep after 3 days of idleness and stay asleep. The stages above describe the policy that applies when they are switched on, and the warning email is the signal that they are. ## Deleting a workspace yourself Deletion you ask for is immediate, not staged. **Workspace settings → delete workspace** removes the workspace and all of its data right away — *This will permanently delete the workspace and all its data. This cannot be undone.* There is nothing scheduled and nothing to cancel, and the workspace's paid seat is released from your subscription as soon as it succeeds. Two exceptions: your Personal Workspace cannot be deleted, and only the owner can delete a workspace. Deleting your **account** removes every workspace you own along with all of their data. See [Settings](/cognee-cloud/ui/settings) and [Account & Billing](/cognee-cloud/functionality/account-and-billing#workspaces). Export anything you need before deleting. The [Activity](/cognee-cloud/ui/activity), [Analytics](/cognee-cloud/ui/analytics), and [Memory Coverage](/cognee-cloud/ui/memory-coverage) pages all offer CSV export. Once a workspace is destroyed there is no recovery in the product — if it happened in error, email [support@cognee.ai](mailto:support@cognee.ai) straight away rather than later: what can be done at all can only be done for a short window, and it is a manual operation rather than a supported flow. ## Related What a workspace is made of, and what sleeping scales to zero. Workspace seats, credits, and what deletion releases.