> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/subscriptions/managing-subscriptions/subscription-statuses-explained.md). # Subscription statuses explained What Active, Paused, Failed and Cancelled mean on a subscription contract, and why Failing is a view rather than a status. Every subscription contract carries a status, shown as a pill on the contract and as tabs across the top of **Subscriptions → Manage Subscriptions**. There are four statuses. The **Failing** tab is the one that catches people out, because it is not a status at all. ### The four statuses | Status | What it means | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Active** | Billing normally on its schedule. This includes contracts that are mid-dunning after a failed payment. | | **Paused** | Billing is stopped temporarily. An indefinite pause runs until someone reactivates the contract. A timed pause shows **Paused until \[date]** and resumes on its own. | | **Failed** | Billing has stopped after payment could not be collected. | | **Cancelled** | Billing has stopped permanently. | See [Pausing, canceling, and reactivating subscriptions](/subscriptions/managing-subscriptions/pausing-canceling-and-reactivating-subscriptions.md) for how to tell the two kinds of pause apart on the Paused tab. ### Failing contracts are still active, failing is not a status The **Failing** tab shows contracts that are still **Active** but whose most recent billing attempt failed, so they are working through your retry schedule. That is why a contract can appear under both **Active** and **Failing**. Nothing is wrong: the contract is alive, Roadmap is retrying it, and it will return to normal if a retry succeeds. The same slice is available as a filter, **Status: Active** plus **Last Payment Status: Failed**. See [Filtering the Subscriptions list](/subscriptions/managing-subscriptions/filtering-the-subscriptions-list.md). {% hint style="info" %} If you want active contracts that are **not** currently struggling, combine **Status: Active** with **Last Payment Status: Successful**. Filtering on Active alone includes the failing ones. {% endhint %} ### How a contract reaches Failed Two routes: * **Dunning ran out.** The last retry failed and the 1-hour grace period passed. See [How to set up payment retries](/subscriptions/pricing-and-billing/how-to-set-up-payment-retries.md). * **You marked it Failed.** An admin-only override that moves a contract straight to Failed without waiting for the retries to play out. See [Marking a subscription as failed](/subscriptions/managing-subscriptions/marking-a-subscription-as-failed.md). A Failed contract needs a working payment method on file before it can be reactivated. Recovering one usually means updating the payment method, confirming it works with **Order now**, then reactivating. {% hint style="info" %} A successful **Order now** on a contract that is mid-dunning takes it out of dunning altogether and reschedules it from that charge. See [Manually charging a subscription (Order Now)](/subscriptions/managing-subscriptions/manually-charging-a-subscription-order-now.md). {% endhint %} ### What each status changes for the customer On an Active contract the customer's **Manage Subscription** menu offers the full set of actions. On a **Paused** or **Failed** contract it narrows to four: **Edit Shipping Address**, **Update Payment Method**, **Reactivate Subscription** and **Cancel Subscription**. Actions that only make sense while billing is running, like **Order now**, **Skip next delivery**, **Reschedule**, **Change delivery frequency** and **Swap Products**, are hidden rather than shown and blocked. Customers cannot reactivate a subscription they have cancelled. See [The customer subscription dashboard: a tour](/subscriptions/storefront-and-accounts/the-customer-subscription-dashboard-a-tour.md). ### Status is not the same as Last Payment Status These are two separate fields and they answer different questions: * **Status** is the state of the contract: is it billing at all? * **Last Payment Status** is the result of the most recent attempt: did the last charge go through? An Active contract with a Failed last payment is mid-dunning. A Failed contract has stopped trying. ### Related guides * [Filtering the Subscriptions list](/subscriptions/managing-subscriptions/filtering-the-subscriptions-list.md) * [Pausing, canceling, and reactivating subscriptions](/subscriptions/managing-subscriptions/pausing-canceling-and-reactivating-subscriptions.md) * [Marking a subscription as failed](/subscriptions/managing-subscriptions/marking-a-subscription-as-failed.md) * [How to set up payment retries](/subscriptions/pricing-and-billing/how-to-set-up-payment-retries.md) * [Manually charging a subscription (Order Now)](/subscriptions/managing-subscriptions/manually-charging-a-subscription-order-now.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.roadmap.so/subscriptions/managing-subscriptions/subscription-statuses-explained.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.