# Managed Subgraphs

Source: https://docs.graphops.xyz/subgraphs/managed-subgraphs

Keep your Subgraph indexed without running the indexing infrastructure yourself. With Managed
Subgraphs, you can monitor progress, prepare a new version while the current one serves queries,
and choose manual releases or follow versions published on The Graph Network.

Pair a Managed Subgraph with an Endpoint Alias to keep the same application URL across upgrades.
If you only need to query an existing deployment, start with [Query your first Subgraph](./getting-started).
To decide whether you need managed indexing, see [Choose your Subgraph setup](./choose-a-setup).

## Start indexing

Before you start, check that you have:

* An Owner or Developer role in the organization.
* A monthly plan for the organization. A plan that is set to cancel counts until it ends. See
[Managed Subgraphs need a monthly plan](../platform/billing-and-credits#managed-subgraphs-need-a-monthly-plan).
* A positive available credit balance. Support can arrange a credit exception when appropriate.
* Room under your organization's [Managed Subgraph limit](#check-your-organizations-limit).
* A deployment with a valid manifest and query schema that uses one
[supported network](./networks) across all data sources and templates.

To have the platform recommend a setup and create the Endpoint Alias with it, choose
**Set up a Subgraph** instead; see
[Choose your Subgraph setup](./choose-a-setup). Otherwise, add the Managed Subgraph directly:

1. Add a Managed Subgraph:

[Create Managed Subgraph](https://platform.graphops.xyz/organizations/current/services/subgraphs/managed/new)

While you
[explore a Subgraph](./guides/discover-public-subgraphs#keep-the-subgraph-in-your-organization),
you can instead choose **Create Managed Subgraph** to start with its
identifier.
2. On **Target**, choose what it follows: **Deployment CID**
for a pinned version that you upgrade manually, or **Graph Network Subgraph ID** to follow
future published versions automatically. A Graph Network Subgraph ID resolves its latest
published deployment before indexing begins.
3. Enter the identifier. A Deployment CID starts with `Qm` and has 46 characters; a Graph Network
Subgraph ID has 43 or 44 characters. The wizard reports an incomplete or malformed identifier
before checking anything, then checks the manifest and shows the deployment's network and start
block. Fix any reported problem, or retry a check that could not complete from the button beside
the field.
4. **Upgrades** states how the target type moves to new versions. Then give the Managed Subgraph a
name your team will recognize, review what will be created, and create it.
5. Optionally add an Endpoint Alias that follows this Managed Subgraph, so your application keeps
one query URL across upgrades. Name it, then choose which version it serves:
**Current version**, selected for you, moves when you promote a version and
suits production; **Next version** serves each version you prepare while it
indexes, so you can test it before you promote it. See
[Choose a target behavior](./guides/manage-aliases#choose-a-target-behavior). Then get its query
endpoint. You can skip this step and add an Endpoint Alias later. If the Endpoint Alias can't be
created, for example because the name is taken, your Managed Subgraph is still created: retry
with another name or skip.

## Know when your data is ready

Check indexing progress and health before relying on new data. A Managed Subgraph's
**Overview** leads with its status and one sentence on what serves your
queries now and what an upgrade in progress is doing. Below it, the Current and Next versions each
show their status, indexing progress, sync lag and Deployment CID, followed by the network, last
hour's indexing cost and Target type. **Versions** shows
each version's indexing progress, and **Endpoint Aliases** lists the Endpoint
Aliases linked to it.

* **Available** means the current version is healthy and
serving queries close to the network head. A small lag can remain, and the page always shows how
many blocks it is behind. Check that lag when your application needs the most recent block.
* Hover over, select, or tap a status label to read its explanation and open its section in
[Statuses](#statuses). A Subgraph error can include
the affected block and a source location to help you correct the deployment. Each version has
its own status: an upgrade failure does not change the status of a healthy serving version.
* **Indexing unavailable** means indexing has stopped. Read
the status explanation for the cause and the suggested next action.
* **Status updated** tells you when the status was received, not which block has
been indexed. **Status delayed** means GraphOps hasn't received a
new status for several minutes; the page keeps showing the last one. Check again before making a
release decision. Promotion waits until a current status arrives.
* **Get query endpoint**, in the **Actions** menu, connects through the Managed Subgraph's earliest created
linked Endpoint Alias, which follows promotions. Without a linked Endpoint Alias, it connects to
the current Deployment CID, which doesn't follow upgrades.

Once you can query the deployment, include `_meta` to check the block and deployment serving your
response. [Monitor sync health](./guides/monitor-sync-health) shows how to detect lag and indexing
errors from your application.

## Statuses

Each status label links here from its explanation. The Managed Subgraph and its Current version
share one status; a Next version has its own while it is prepared for promotion.

### Setting up

GraphOps is preparing the deployment for managed indexing, is waiting for indexing capacity, or
hasn't received its first indexing status yet. Indexing starts without any action from you.

### Syncing

The deployment is catching up to the network head. Queries succeed but can return older data, so
check the sync lag before relying on recent blocks.

### Available

The deployment is healthy and serving queries close to the network head. A small lag can remain;
the page shows how many blocks it is behind. Routine maintenance, such as moving the deployment to
different storage, keeps this status while the deployment keeps serving. If indexing reports
errors that don't stop it, the status explanation lists them; some data can be incomplete.

### Indexing unavailable

Indexing has stopped, usually because of a Subgraph error. The explanation names the cause, the
affected block when known, and the suggested next action. See
[Managed indexing has stopped](./troubleshooting#managed-indexing-has-stopped).

### Paused

Managed indexing is paused or being paused. A paused deployment doesn't index new blocks.

### Removing and Removed

The deployment is being removed, or has been removed, for example after a Next version was
cancelled or the Managed Subgraph was archived.

### Ready to promote

The Next version is healthy and ready to become the Current version. Promote it, or let automatic
promotion move it when its Target type follows The Graph Network.

### Cancelling

Preparation of the Next version is being cancelled. The Current version keeps serving queries.

## Upgrade without changing your application URL

Your **Current version** continues serving queries while you prepare a
**Next version**. Your Endpoint Alias moves only when you promote:

*Current serves queries through every stage of an upgrade. Your Endpoint Alias moves only when you promote a Next version that meets the readiness checks, and returning to the previous deployment takes another upgrade.*

- Start upgrade: Enter the next Deployment CID on the same network. Review the schema comparison before you continue. (Endpoint Alias serves: Qm…a1f4; Current: Qm…a1f4 Available; Next: Qm…7c2e Setting up)
- Index and test: Next indexes while Current keeps serving queries. Both versions accrue indexing charges. (Endpoint Alias serves: Qm…a1f4; Current: Qm…a1f4 Available; Next: Qm…7c2e Syncing)
- Ready to promote: Next is healthy and meets the readiness checks. Test its query results before you promote it. (Endpoint Alias serves: Qm…a1f4; Current: Qm…a1f4 Available; Next: Qm…7c2e Ready to promote)
- Promote version: Endpoint Aliases that target the Managed Subgraph move to the promoted version. The previous version accrues charges until its removal finishes. (Endpoint Alias serves: Qm…7c2e; Current: Qm…7c2e Available; Previous version: Qm…a1f4 Removing)

1. Choose **Start upgrade** from the page's actions and enter the next
Deployment CID. GraphOps checks it as you enter it, and **Continue** becomes
available once the check passes. It must use the same network; see
[Deploy your own Subgraph](./guides/deploy-with-graph-cli) to get one.
2. Review the upgrade before you start it: the next version's details, what each linked Endpoint
Alias does with it (Current version aliases move to it when you promote it; Next version aliases
serve it while it indexes), and the schema comparison. Without a Next version alias, the review
offers to create one. If the comparison reports breaking changes, update and test affected
clients before proceeding. You can deliberately continue with a breaking change. If GraphOps
can't start the upgrade with that version, the review sends you back to enter another; if the
start fails for any other reason, start it again from the review.
3. Let the next version index, then test its query results. A compatible schema does not guarantee
unchanged data or mapping behavior.
4. In **Versions**, choose **Promote version** when the next version is healthy and meets the service's indexing readiness
checks. Review its indexing progress against the network head before promoting.

An Endpoint Alias with a **Managed Subgraph** target and the
**Current version** target behavior follows the version you promote, so your clients keep the same URL. To
test the next version through a stable URL before promoting it, create a second Endpoint Alias with
the **Next version** target behavior. It serves the Next version while it's being indexed and falls
back to Current when you cancel the upgrade or Next can't serve. An Endpoint Alias with a
**Deployment CID** target stays on that CID. Existing Endpoint Aliases only
follow these upgrades after you explicitly target the Managed Subgraph. See
[Manage Endpoint Aliases](./guides/manage-aliases#choose-a-target-behavior).

You can cancel an upgrade before promotion. After promotion, returning to a previous deployment
requires another upgrade; it is not an instant rollback. Keep the previous CID and test your
recovery plan before a production release. [Develop and release a Subgraph](./guides/develop-and-release)
uses these upgrades as a release workflow for your own Subgraph.

## Follow published upgrades automatically

Choose a Graph Network Subgraph ID at creation, or [change the target type](#change-the-target-type)
of an existing Managed Subgraph. Following authorizes indexing and promotion of future published
versions, including breaking schema changes. Review the displayed schema comparison and prepare
clients for changes published by the Subgraph owner.

You don't stage these upgrades in GraphOps:

* When the owner publishes a new version on The Graph Network, the latest version becomes Next
while Current continues serving.
* Next promotes when it is healthy, attached, and ready to serve queries.
* If another release arrives first, the latest valid release replaces Next. Serving Current can
therefore be older than the previous published network version.
* Missing or deprecated IDs, lookup failures, invalid releases, and network changes hold the
existing versions and Endpoint Alias mappings. Check the last resolution and tracking error in
the Managed Subgraph's **Versions**.

A paused Managed Subgraph that follows a Graph Network Subgraph ID keeps following it and resumes
with the latest version.

An Endpoint Alias with a **Graph Network Subgraph ID** target follows the same publications
through indexers on The Graph Network, independently of this Managed Subgraph's indexing. Use a
**Managed Subgraph** target when the Endpoint Alias should follow this
Managed Subgraph's serving Current version. [Manage Endpoint Aliases](./guides/manage-aliases)
shows when each target moves.

## Change the target type

A Managed Subgraph's Target type decides how it moves to new versions. A
**Deployment CID** target stays on the currently indexing deployment until you
[upgrade it](#upgrade-without-changing-your-application-url). A
**Graph Network Subgraph ID** target
[follows published upgrades](#follow-published-upgrades-automatically). The name, version history,
and linked Endpoint Aliases stay with the Managed Subgraph either way.

1. Choose **Change target type** from the Managed Subgraph's
actions.
2. Choose what it should follow. For a Graph Network Subgraph ID, enter the ID and wait for it to
resolve.
3. Review the target type, Current CID, and Next CID now and after saving, and what each linked
Endpoint Alias serves.
4. Select **Save target type**. The change takes effect immediately, and the currently indexing
deployment stays the Current version.

To follow a Graph Network Subgraph ID, the Managed Subgraph must be active with no staged manual
upgrade, and the ID must use the same blockchain network. The currently indexing deployment must
also be one of the versions published to that ID; if it isn't,
[publish it](./guides/deploy-with-graph-cli#publish-on-the-graph-network-optional) first. Promote
or cancel a staged upgrade before you change the target type. To follow a different Subgraph ID,
change the target type to a Deployment CID first.

Changing to a Deployment CID stops following and retires a staged Next version: its indexing stops,
and Next version Endpoint Aliases serve the Current version. Current version Endpoint Aliases are
unchanged. **Start upgrade** becomes available again, so you stage each new
version yourself.

## Plan indexing costs

Managed indexing charges depend on how long each version receives indexing service, its entity
count, and its stored data. Charges can accrue during setup and syncing, not only when you send
queries. Each Managed Subgraph shows an estimate of its managed indexing credits per month: the
credits charged for its last full hour of indexing, multiplied by 730 hours in an average month. The
info icon beside the estimate shows the calculation. The estimate appears after the first full hour
has been charged and changes as entity count and stored data change. If two of your Managed
Subgraphs use the same Deployment CID, each shows that CID's total.

Current rates as of Nov 14, 2026, 12:11 AM UTC.

| Usage component | Applies to | Rate |
| --- | --- | --- |
| Queries | Default | 50 credits per query |
| Queries | Billing mode: managed | 0 credits per query |
| Response bytes | Default | 1,500,000 credits per GiB |
| Response bytes | Billing mode: managed | 0 credits per GiB |
| Managed allocated time | Default | 100,000 credits per hour |
| Managed entity time | Default | 77,000 credits per 1 million entity-hours |
| Managed storage time | Default | 3,850 credits per GiB-hour |

The managed query rate applies when your organization's request resolves to its managed deployment,
whether you use a Deployment CID, Endpoint Alias, or Graph Network Subgraph ID.

During upgrades, both Current and Next can accrue indexing charges. The previous version can
continue accruing charges until its indexing service is removed. Your organization limit counts the
Managed Subgraph once, even while two versions are active. Separate Managed Subgraphs sharing a CID
each count toward the limit, and their attached registrations are charged separately.

If credits run out while your organization has a monthly plan, existing indexing can continue
accruing charges until the grace period ends and disconnection is confirmed. Without a monthly plan,
or while a plan payment needs attention, there is no grace period and indexing stops as soon as the
balance reaches zero. [Automatic top-ups](../platform/billing-and-credits#automatic-top-ups) add
credits before that happens. See
[Managed Subgraphs during a pause](../platform/billing-and-credits#managed-subgraphs-during-a-pause)
for stopping and recovery after adding credits.

## Check your organization's limit

Each organization can have up to 10 Managed Subgraphs by default, whatever its plan size. Contact
[GraphOps support](../platform/support-and-status) to raise the limit for your organization.

If you add a Managed Subgraph without a monthly plan, the platform asks an owner or billing admin to
choose one. If your organization has reached its limit, the platform points you to support.

Paused Subgraphs and those being removed still count toward the limit. Room becomes available after
removal finishes.

## Stop indexing a Subgraph

Removal is irreversible and stops managed indexing. Check that your applications no longer depend
on that service before proceeding.

1. If it follows a Graph Network Subgraph ID and has a Next version, use
**Change target type** to change it to a Deployment CID, which
retires the Next version. Otherwise, cancel a staged manual upgrade.
2. Delete the Endpoint Aliases that target this Managed Subgraph, or change them to Deployment CID
targets. The delete dialog lists each one that still follows it, with links to change its target
or delete it, and stays disabled until none remain.
3. Select **Delete** and confirm deletion of the Managed Subgraph.
4. Check that removal finishes before its place in your limit or its name becomes available again.

The record remains under **Archived**, with its version history. Once removal finishes, you can
reuse the name for a new Managed Subgraph; the archived record remains available. You can create
another resource with the same CID while a peer is still active.

## Next steps

* [Manage Endpoint Aliases](./guides/manage-aliases): Give your application a stable endpoint that follows promotions.
* [Monitor sync health](./guides/monitor-sync-health): Check lag and indexing errors from your application with `_meta`.
* [Troubleshooting](./troubleshooting): Resolve validation, status, or query errors.