Skip to main content
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.
A deployment can be marked healthy while its processor is waiting on a slow RPC, repeatedly retrying an error, or making no indexing progress.

​
Metrics endpoints

Each processor exposes Prometheus metrics through its slot URL:
The same processor is available through every tag assigned to the slot:
<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: 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:
An increasing lag means the processor is losing ground. A flat lag can still be stale if the reported source height is stale.
Alert on both lag and time since the last processed block. Either signal alone can miss an upstream source that has stopped advancing.

​
Logs

Follow the processor selected by a stable tag:
Filter for an error:
See Inspect logs 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 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 has a copyable diagnostic checklist.

Related topics

Reliability and monitoringData freshness monitoringSolana Portal API ReferenceEVM Portal API ReferenceSolana Portal API