# Verifying your setup

Before you can actually start validating, it is recommended that you make sure your node is connected to the network, sees other participants, is receiving updates and is able to respond to RPC calls.

#### Logs

First check the logs. Your node will likely start out by synchronizing with the general network, and after a while start getting blocks in real time. To get the logs out of docker, you will need to run:

```bash
docker logs <your_nodes_name> # or the container name you have chosen with `--container_name`
```

{% hint style="info" %}
You can run `docker logs --follow <your_nodes_name>` to get the output in real time.
{% endhint %}

{% hint style="warning" %}
To **get the last 24h of logs as a file**, use the following command:\
`docker logs --since 24h <your_nodes_name> > file.log 2>&1`
{% endhint %}

This should return some lines, either the node is syncing, in which case an example of a healthy result of this command follows.

```bash
2025-03-14 13:58:19 ✨ Imported #45058440 (0xa96a…e16e)    
2025-03-14 13:58:19 ✨ Imported #45058441 (0x6ae3…7a19)    
2025-03-14 13:58:19 ✨ Imported #45058442 (0x08ae…a428)    
2025-03-14 13:58:19 ✨ Imported #45058443 (0x0e1d…82d1)    
2025-03-14 13:58:19 ✨ Imported #45058444 (0x9498…8e51)    
2025-03-14 13:58:19 ✨ Imported #45058445 (0x4adf…ffda)    
2025-03-14 13:58:19 ✨ Imported #45058446 (0xbcfc…47c0)    
2025-03-14 13:58:19 ✨ Imported #45058447 (0xaaa1…05ae)    
2025-03-14 13:58:19 ✨ Imported #45058448 (0x940a…88d7)    
2025-03-14 13:58:19 ✨ Imported #45058449 (0xec3f…0a1f)    
2025-03-14 13:58:19 ✨ Imported #45058450 (0x9a58…dbcc)    
2025-03-14 13:58:19 ✨ Imported #45058451 (0xc581…f641)    
2025-03-14 13:58:19 ✨ Imported #45058452 (0x772a…ffec)    
2025-03-14 13:58:19 ✨ Imported #45058453 (0x9be6…495f)    
2025-03-14 13:58:19 ✨ Imported #45058454 (0x90e0…dceb)    
2025-03-14 13:58:19 ✨ Imported #45058455 (0x5bbb…7659)    
2025-03-14 13:58:19 ✨ Imported #45058456 (0x9975…5889)    
2025-03-14 13:58:19 ✨ Imported #45058457 (0xe46b…621b)    
2025-03-14 13:58:19 ✨ Imported #45058458 (0x19c3…4795)    
2025-03-14 13:58:19 ✨ Imported #45058459 (0x04bc…407d)    
2025-03-14 13:58:19 ✨ Imported #45058460 (0xc505…d30a)    
```

Note multiple imports within one second. In some cases (if the node is already synced) the logs might contain an import per second, looking like this:

```bash
2025-03-14 14:03:52 ✨ Imported #88325206 (0x892e…a4a0)
2025-03-14 14:03:53 ✨ Imported #88325207 (0x69fc…3ef8)
2025-03-14 14:03:54 ✨ Imported #88325208 (0x20f7…f3da)
2025-03-14 14:03:55 ✨ Imported #88325209 (0x838d…dd6e)
```

Which is also a sign of a healthy node. There will also be other loglines, but if these look alright at this point the node should be fine.

#### Endpoints

Next you should check whether the RPC and WebSocket endpoints are externally accessible. They **should** be accessible for archivists and **categorically should not** be accessible for validators.

The tests should preferably be run on a machine outside of the local network containing the node, although many of them should give the same results as long as they are not run on the same machine.

**RPC**

To check whether RPC calls work execute

```bash
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "rpc_methods"}' https://example.com:9944
```

using your own address instead of example.com, obviously. For nodes without a DNS address you should omit the `https://`. This should return an extensive JSON response containing many RPC call names for archivists and some kind of error (depending on your exact setup) for validators.

Additionally check whether unsafe RPC call are possible to execute on externally available nodes:

```bash
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "system_unstable_networkState"}' https://example.com:9944
```

This should return some kind of error on both archivists and validators.

Finally check whether you can perform unsafe operations on validators internally. There are multiple ways this could be done, for this one we assume you have ssh access to the machine:

```bash
ssh -L 9944:127.0.0.1:9945 example.com
```

In a separate terminal on the same machine run:

```bash
curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "system_unstable_networkState"}' localhost:9944
```

This should return a huge JSON response for validators and at most an error for archivists.

**WebSocket**

The easiest way of checking correct websocket accessibility is to attempt connecting using one of the polkadot.js instances. Any should work, but we recommend the appropriate wallet AlephZero is hosting, i.e. <https://test.azero.dev/> for testnet and [https://azero.dev/](https://test.azero.dev/) for mainnet, to minimize confusion. Once there, click on the AlephZero logo, and then on the “Development” tab in the list that appears. In the “Custom endpoint” field fill your address in the form:

```bash
wss://example.com:9944
```

After a moment the usual view of a AlephZero connected wallet should appear, indistinguishable from any other archivist, for archivists. For validators this should get stuck on loading and never connect.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.alephzero.org/aleph-zero/use/validate/running-an-aleph-node-on-testnet/verifying-your-setup.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.