> ## Documentation Index
> Fetch the complete documentation index at: https://docs.goldsky.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Stalled subgraph detection

> Learn how Goldsky monitors for stalled subgraphs and automatically pauses them to optimize resources

Goldsky automatically monitors your subgraphs for indexing issues and notifies you when a subgraph becomes stalled. This helps ensure your applications stay healthy and resources are used efficiently.

## What is a stalled subgraph?

A subgraph is considered **stalled** when it stops making indexing progress for an extended period. This can happen due to:

* Errors in the subgraph mapping code that cause repeated failures
* Issues with the underlying blockchain data source
* Resource constraints preventing the subgraph from processing new blocks
* Unhandled edge cases in the subgraph logic

Stalled subgraphs consume resources without providing value, and may indicate underlying issues that need attention.

## Automatic monitoring

Goldsky continuously monitors all deployed subgraphs for indexing progress. When a subgraph is detected as stalled:

1. **Warning notification** - All team members on the project receive an email alerting them that the subgraph has stalled
2. **Continued monitoring** - Goldsky continues to monitor the subgraph to see if it recovers
3. **Auto-pause** - If the subgraph remains stalled, it may be automatically paused to conserve resources

## Email notifications

When Goldsky detects issues with your subgraph, you'll receive email notifications:

### Stall warning email

When a subgraph is first detected as stalled, all team members on the project receive a warning email. This email includes:

* The name of the affected subgraph
* The project the subgraph belongs to

This gives you an opportunity to investigate and resolve the issue before any automatic action is taken.

### Auto-pause notification email

If a stalled subgraph is automatically paused, all team members receive a notification email confirming:

* The subgraph has been paused
* The name of the affected subgraph
* The project the subgraph belongs to

<Note>
  These emails are sent to all team members regardless of notification preferences, as they relate to critical account actions that may affect your applications.
</Note>

## What to do when you receive a stall notification

When you receive a stall warning or auto-pause notification:

1. **Check your subgraph status** - Use the [Goldsky dashboard](https://app.goldsky.com) or CLI to view the current status and any error logs:
   ```bash theme={null}
   goldsky subgraph list
   ```

2. **Review error logs** - Look for any errors or warnings that might indicate why the subgraph stalled

3. **Fix the underlying issue** - Common fixes include:
   * Updating your subgraph mapping code to handle edge cases
   * Fixing bugs in your AssemblyScript handlers
   * Adjusting your subgraph manifest configuration

4. **Resume or redeploy** - Once you've addressed the issue:
   * If the subgraph was paused, resume it from the dashboard or CLI
   * If code changes were needed, redeploy the updated subgraph

```bash theme={null}
# Resume a paused subgraph
goldsky subgraph resume <name>/<version>

# Or redeploy with fixes
goldsky subgraph deploy <name>/<version> --path .
```

5. **Monitor recovery** - After resuming or redeploying, monitor the subgraph to ensure it's making progress again

## Preventing stalled subgraphs

To minimize the risk of your subgraphs stalling:

* **Test thoroughly** - Test your subgraph against historical data before deploying to production
* **Handle errors gracefully** - Add proper error handling in your mapping code
* **Monitor regularly** - Check your subgraph status periodically in the dashboard
* **Set up alerts** - Use [webhooks](/subgraphs/webhooks) to get notified of subgraph events
