# Sync and reorgs

Source: https://docs.graphops.xyz/subgraphs/concepts/sync-and-reorgs

Decide when a Subgraph result is fresh enough to show and final enough to act on. A Subgraph
indexes chain data over time and serves queries from the latest indexed block, which can trail the
chain head. GraphOps Subgraphs are reorg-aware, so recently indexed data can be corrected when the
chain reorganizes.

_Queries are served from the highest indexed block, which _meta.block.number reports. Recently indexed data can still be corrected by a reorganization, so compare it with the network's finality before treating it as irreversible._

- _meta.block.number: block N in this example.
- Chain head: block N+2 in this example.

## Metadata query

Use `_meta` to inspect the indexed block and indexing-error state:

```graphql
query SyncStatus {
  _meta {
    deployment
    block {
      number
      hash
    }
    hasIndexingErrors
  }
}

```

Output

```json
{
  "data": {
    "_meta": {
      "deployment": "QmTZ8ejXJxRo7vDBS4uwqBeGoxLSWbhaA7oXa1RvxunLy7",
      "block": {
        "number": 26285620,
        "hash": "0x7931a9fc337c615e67690a3083685a5680a72653718c13451f7697ea856b14f3"
      },
      "hasIndexingErrors": false
    }
  }
}
```

The deployment that served this request

Highest indexed block; track it over time

Include in support requests

Alert when true

## Freshness model

| Signal                    | Meaning                                                                                                |
| ------------------------- | ------------------------------------------------------------------------------------------------------ |
| `_meta.block.number`      | Highest indexed block served by the Subgraph endpoint.                                                 |
| `_meta.block.hash`        | Hash of the indexed block. Use it for diagnostics.                                                     |
| `_meta.deployment`        | Deployment serving the query. Useful when testing Endpoint Alias or Graph Network Subgraph ID changes. |
| `_meta.hasIndexingErrors` | Whether indexing errors are present for the deployment.                                                |

## Reorg-aware behavior

Reorg-aware indexing means the served entity state can be corrected after a chain reorganization.
Applications should:

* Treat recently indexed data as potentially revisable.
* Use `_meta.block.number` and `_meta.block.hash` in logs for support and debugging.
* Avoid assuming that a newly indexed entity is final for settlement or irreversible user-facing
state.
* Compare the indexed block with your network's finality information before treating a result as
irreversible; elapsed time alone does not establish finality.

## Apply the model

* Monitor `_meta` on health checks and critical queries.
* Log the endpoint mode: Deployment CID, Graph Network Subgraph ID, or Endpoint Alias.
* After changing an Endpoint Alias target, confirm `_meta.deployment` matches the expected deployment.
* If `_meta.hasIndexingErrors` is true, inspect query results carefully and contact
[GraphOps support](https://platform.graphops.xyz/organizations/current/overview?support=open).

## Next steps

* [Monitor sync health](../guides/monitor-sync-health): Build a `_meta` health check with lag and error alerts.
* [Manage Endpoint Aliases](../guides/manage-aliases): Confirm the serving deployment after a target change.
* [Troubleshooting](../troubleshooting): Diagnose stale results and indexing errors.