Congrid verifier monitoring works best when you separate three observations: whether the services are running, whether their local endpoints respond, and what the assignment query reports. Each observation answers a different operational question.
This checklist is for an already installed verifier. Use the Linux and macOS verifier overview and the current official verifier guide for setup. Use the checks below to inspect the deployment and collect comparable evidence.
Record the deployment you are checking
Before comparing results, note the host, operating system, installation mode, verifier public address, and observation time with its timezone. Record the RPC and gRPC endpoints configured for that deployment.
The official guide distinguishes a full-stack installation from existing-node mode, selected with --components-only. Full-stack mode includes the chain node, Chroma, publisher indexer, and verifier worker. Existing-node mode manages the supporting components and connects them to an existing node. Its monitoring inventory therefore differs.
Use the mode actually deployed. A missing installer-managed node service is not enough to diagnose a fault on a host using existing-node mode.
Inspect service state and recent logs
For a full-stack Linux deployment, the current guide lists:
sudo systemctl status congrid-node congrid-chroma \
congrid-indexer congrid-verifier
For existing-node mode, inspect the three services the installer manages:
sudo systemctl status congrid-chroma congrid-indexer congrid-verifier
Check each reported unit, including its state and recent messages. The systemctl manual describes status as human-readable runtime information with recent journal data. A running process is one signal; it does not establish that assignments are being completed.
To follow the verifier journal, the Congrid guide provides:
sudo journalctl -u congrid-verifier -f
The journalctl manual explains that -u selects a unit and -f continues printing new entries. Press Ctrl-C when you have captured the observation you need. Preserve the error text and its timestamp rather than summarizing every failure as “the verifier is down.”
On macOS, the official guide provides these job and log checks:
launchctl print "gui/$(id -u)/net.congrid.verifier"
tail -f "$HOME/.content-grid/logs/verifier.log"
The displayed log path is the guide's full-stack path. Existing-node mode uses separate component state; confirm the deployed log location before interpreting an absent file. Record the job output and relevant log entries for the same observation period.
Check the documented local health endpoints
Run the following on the verifier host. The loopback address 127.0.0.1 refers to the machine running the command, so running it on an unrelated laptop checks that laptop instead.
curl -fsS http://127.0.0.1:8000/healthz
curl -fsS http://127.0.0.1:9100/healthz
curl -fsS http://127.0.0.1:9200/healthz
These are the local health checks currently listed in the verifier guide. For each endpoint, record the time, response or error, and whether the command succeeded. Keep the observations separate so a successful response from one endpoint does not hide a failure at another.
A health response also has a narrower scope than successful verification work. Combine it with service logs and assignment evidence before concluding that the full workflow is healthy.
Query assignments with the correct address and binary
The current guide uses this Linux full-stack query. Replace <verifier-address> with the verifier public address you intend to inspect:
/usr/local/bin/content-grid-d verifier assignments <verifier-address> \
--node tcp://127.0.0.1:26657 \
--grpc-addr 127.0.0.1:9090 \
--grpc-insecure \
--include-finalized -o json
Use the binary appropriate to the documented installation mode:
| Deployment | Binary path |
|---|---|
| Linux full stack | /usr/local/bin/content-grid-d |
| Linux existing-node mode | /usr/local/libexec/congrid/content-grid-d-client |
| macOS full stack | ~/.local/bin/content-grid-d |
| macOS existing-node mode | ~/.local/share/congrid/libexec/content-grid-d-client |
The example targets the local RPC and gRPC endpoints shown in the guide. If your deployment uses different configured endpoints, check them against its setup record before diagnosing connectivity. The --grpc-insecure option belongs to this documented local example; do not copy it into an unreviewed remote connection.
Save the query result or error with its timestamp. Because the example requests finalized entries too, inspect the reported state before treating returned records as unfinished work. An unsuccessful query is a collection failure, not evidence of an empty assignment list.
When investigating stalled work, compare observations for the same verifier address and use the assignment information actually reported by the query alongside the logs. Do not invent status labels or assume a universal completion deadline. A single quiet observation cannot explain why no new work appeared.
Route the symptom to the next useful check
| Observation | Next evidence to collect |
|---|---|
| A managed service is failed or inactive | Its runtime state and the relevant journal or job log |
| A local health check fails | The exact endpoint, command error, and corresponding service configuration |
| The assignment query cannot connect | The queried RPC and gRPC addresses and whether they match the deployment record |
| Services and endpoints respond but work appears stalled | Repeated assignment observations and logs covering the affected period |
| A single publisher check fails | The reported check evidence and the publisher's deployed homepage requirements |
The last case needs a different investigation from a host-wide service failure. Congrid's publisher guide documents homepage and member-badge requirements; the badge-link troubleshooting guide covers one specific mismatch. A website repair and confirmation of its resulting status remain separate observations.
Keep an incident record another operator can use
Use a compact record with the host and installation mode, observation window and timezone, verifier public address, affected service or endpoint, exact error, and the assignment-query result. Add the last relevant deployment change and the next check with a named owner.
After a repair, repeat the check that originally failed and review the affected work. A restart alone is not closure evidence. Record what recovered and what remains unresolved.
The official guide calls for attention to service exits, RPC disconnects, failed checks, and assignment backlog. Set review and alert rules around those signals using the operating context you can verify. Keep protocol participation records separate from publisher referral traffic and organic search rankings; none substitutes for service and assignment evidence.
Use the publisher-versus-verifier responsibility checklist to assign ownership and the current guides to confirm instructions before the next operational change.