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

# Monitoring

> Monitor SQD Cloud health, indexing progress, lag, and custom Prometheus metrics.

SQD Cloud displays service health and processor metrics, but these signals answer different questions:

* **Service health** tells you whether the process and Cloud route are running.
* **Processor progress** tells you whether the indexer continues to commit blocks.
* **Data freshness** compares processed height or timestamp with the expected source head.

<Warning>
  A deployment can be marked healthy while its processor is waiting on a slow
  RPC, repeatedly retrying an error, or making no indexing progress.
</Warning>

## Metrics endpoints

Each processor exposes Prometheus metrics through its slot URL:

```text theme={"system"}
https://<org>.squids.live/<name>@<slot>/processors/<processor>/metrics
```

The same processor is available through every tag assigned to the slot:

```text theme={"system"}
https://<org>.squids.live/<name>:<tag>/processors/<processor>/metrics
```

`<processor>` defaults to `processor` for a single unnamed service. For a multi-processor manifest, use the processor's `name`.

Use the tag endpoint for production monitoring so the scrape target follows a zero-downtime cutover.

## Indexing metrics

The built-in metrics include:

| Metric                       | Meaning                                                          |
| ---------------------------- | ---------------------------------------------------------------- |
| `sqd_processor_last_block`   | Last block committed by the processor                            |
| `sqd_processor_chain_height` | Current height reported by the active data source when available |

Inspect the endpoint for the complete list produced by your SDK version.

### Diagnose progress

1. Record `sqd_processor_last_block` at two points in time.
2. If it does not increase, inspect processor logs.
3. Compare it with `sqd_processor_chain_height`.
4. Confirm that the reported source height matches an independent source for the chain.
5. Check whether the upstream Portal, SQD Network dataset, or RPC has the required historical range.

The useful lag calculation is:

```text theme={"system"}
lag = sqd_processor_chain_height - sqd_processor_last_block
```

An increasing lag means the processor is losing ground. A flat lag can still be stale if the reported source height is stale.

<Tip>
  Alert on both lag and time since the last processed block. Either signal alone
  can miss an upstream source that has stopped advancing.
</Tip>

## Logs

Follow the processor selected by a stable tag:

```bash theme={"system"}
sqd logs -n <name> -t production -c processor -f --since 30m
```

Filter for an error:

```bash theme={"system"}
sqd logs -n <name> -t production -c processor -l error --since 6h
```

See [Inspect logs](/en/cloud/resources/logging) for all filters.

Repeated RPC errors, HTTP 429 responses, missing historical blocks, and request timeouts are upstream data-source symptoms. Increasing Cloud compute usually does not correct them.

## Multi-processor deployments

Monitor each named processor independently. One processor can be current while another is stalled.

For TypeORM-based multi-processor squids, processor state may be stored in separate database schemas. Do not assume every processor writes to `squid_processor.status`; inspect the `stateSchema` configured by that processor.

## Background jobs

A [background processor service](/en/cloud/resources/background-jobs) should expose job-specific metrics such as:

* runs by result;
* last successful run timestamp;
* duration;
* rows affected;
* lock-contention or skipped-run count.

It is not a chain processor, so it may not expose meaningful block-height metrics. Alert on its actual schedule and last successful completion.

## External monitoring

Scrape the tag-based metrics URL from Prometheus or another compatible service. A basic production dashboard should show:

* last processed block;
* source height and lag;
* processing rate;
* processor restarts and errors;
* API request latency and error rate from the client or API service;
* database connections, storage, and slow queries where available;
* last success and duration for scheduled jobs.

Do not include deployment keys, database URLs, or other credentials in metric labels.

## Support information

When requesting help, provide:

* organization and squid name;
* exact slot, not only the tag;
* affected processor name;
* time range and timezone;
* first relevant error and a short surrounding log window;
* last processed block and expected chain height;
* whether the same commit works locally.

The [troubleshooting guide](/en/cloud/troubleshooting) has a copyable diagnostic checklist.


## Related topics

- [Reliability and monitoring](/en/network/introduction/reliability-and-monitoring.md)
- [Data freshness monitoring](/en/sdk/pipes-sdk/solana/guides/advanced-topics/latency-monitoring.md)
- [Solana Portal API Reference](/en/portal/solana/api.md)
- [EVM Portal API Reference](/en/portal/evm/api.md)
- [Solana Portal API](/en/portal/solana/overview.md)