OffchainLabs · pete-vielhaber · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026
diff --git a/docs/launch-arbitrum-chain/operate/monitoring.mdx b/docs/launch-arbitrum-chain/operate/monitoring.mdx
@@ -57,7 +57,7 @@ nitro --metrics \
   --metrics-server.port 6070
 ```
 
-For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx).
+For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/nitro/node-monitoring.mdx).
 
 The signals that are not Nitro metrics — onchain events and account balances on the parent chain — are called out explicitly in each table below.
 

diff --git a/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx b/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx
@@ -120,7 +120,7 @@ extraEnv:
     value: 'value'
 ```
 
-For the allocator details, the `GOMEMLIMIT` formula, and `MALLOC_ARENA_MAX`, see the [memory management deep-dive](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx) and the [memory management section](/run-arbitrum-node/02-run-full-node.mdx#memory-management) of the Docker full-node guide.
+For the allocator details, the `GOMEMLIMIT` formula, and `MALLOC_ARENA_MAX`, see the [memory management deep-dive](/run-arbitrum-node/nitro/node-tuning.mdx) and the [memory management section](/run-arbitrum-node/02-run-full-node.mdx#memory-management) of the Docker full-node guide.
 
 ## Step 3: First sync from a snapshot
 

diff --git a/docs/run-arbitrum-node/02-run-full-node.mdx b/docs/run-arbitrum-node/02-run-full-node.mdx
@@ -129,7 +129,7 @@ Under heavy RPC load or during operations such as large `debug_traceBlockByNumbe
 - `--node.resource-mgmt.mem-free-limit`: Declines incoming RPC requests when free system memory drops below the specified threshold (e.g., `--node.resource-mgmt.mem-free-limit=4GiB`). This helps protect the node from OOM under high request load.
 - `GOMEMLIMIT` environment variable: Sets a soft memory limit for the Go runtime garbage collector (e.g., `GOMEMLIMIT=48GiB` for a 64 GB machine), helping reduce memory spikes.
 
-For an in-depth breakdown of Nitro's memory allocators, cache tuning, and OOM mitigations, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx).
+For an in-depth breakdown of Nitro's memory allocators, cache tuning, and OOM mitigations, see [node tuning](/run-arbitrum-node/nitro/node-tuning.mdx).
 
 :::tip
 For Docker deployments, you can set these in your `docker run` command:

diff --git a/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx b/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx
@@ -48,7 +48,7 @@ Block validation is not yet supported with the path-based state scheme. In other
 - Fast, local NVMe SSD storage is required for reasonable sync speed.
 - PathDB snapshot auto-downloads with `--init.latest` are not yet supported.
 
-For guidance on tuning cache sizes and memory usage on PathDB archive nodes, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx).
+For guidance on tuning cache sizes and memory usage on PathDB archive nodes, see [node tuning](/run-arbitrum-node/nitro/node-tuning.mdx).
 
 To enable PathDB on your archive node, start your node with the following flags:
 

diff --git a/.../run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx b/.../run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx
@@ -12,7 +12,7 @@ Switching from LevelDB to Pebble in Ethereum's Geth client provides several adva
 
 While Pebble provides better resilience and potentially improved performance, deciding to switch should consider your specific needs and the possible effects of a full resync on your operations.
 
-For background on how the database backend interacts with Nitro's caches and memory usage, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx).
+To learn how the database backend interacts with Nitro's caches and memory usage, see [node tuning](/run-arbitrum-node/nitro/node-tuning.mdx).
 
 <VanillaAdmonition type="note">
 

diff --git a/docs/run-arbitrum-node/nitro/cli-flags-reference.mdx b/docs/run-arbitrum-node/nitro/cli-flags-reference.mdx
@@ -20,7 +20,8 @@ This page lists every CLI flag accepted by the Nitro node binary. For explanatio
 
 - [Configuration system](/run-arbitrum-node/nitro/configuration-system)
 - [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries)
-- [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+- [Node tuning](/run-arbitrum-node/nitro/node-tuning)
+- [Node monitoring](/run-arbitrum-node/nitro/node-monitoring)
 - [DA tools reference](/run-arbitrum-node/nitro/da-tools-reference)
 
 **Total flags:** 724 across 23 namespaces.
@@ -113,7 +114,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys
 
 ## execution
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node tuning](/run-arbitrum-node/nitro/node-tuning)
 
 <details>
 <summary>execution flags (164)</summary>
@@ -289,7 +290,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning
 
 ## file-logging
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node tuning](/run-arbitrum-node/nitro/node-tuning)
 
 <details>
 <summary>file-logging flags (8)</summary>
@@ -426,7 +427,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys
 
 ## metrics
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node monitoring](/run-arbitrum-node/nitro/node-monitoring)
 
 <details>
 <summary>metrics flags (1)</summary>
@@ -439,7 +440,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning
 
 ## metrics-server
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node monitoring](/run-arbitrum-node/nitro/node-monitoring)
 
 <details>
 <summary>metrics-server flags (3)</summary>
@@ -454,7 +455,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning
 
 ## node
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node tuning](/run-arbitrum-node/nitro/node-tuning)
 
 <details>
 <summary>node flags (408)</summary>
@@ -920,7 +921,7 @@ Related guide: [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli
 
 ## pprof
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node monitoring](/run-arbitrum-node/nitro/node-monitoring)
 
 <details>
 <summary>pprof flags (1)</summary>
@@ -933,7 +934,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning
 
 ## pprof-cfg
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node monitoring](/run-arbitrum-node/nitro/node-monitoring)
 
 <details>
 <summary>pprof-cfg flags (2)</summary>
@@ -961,7 +962,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys
 
 ## validation
 
-Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring)
+Related guide: [Node tuning](/run-arbitrum-node/nitro/node-tuning)
 
 <details>
 <summary>validation flags (26)</summary>

diff --git a/docs/run-arbitrum-node/nitro/node-monitoring.mdx b/docs/run-arbitrum-node/nitro/node-monitoring.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Node monitoring'
+sidebar_label: 'Node monitoring'
+description: 'Enable the Nitro metrics server, scrape Prometheus metrics, monitor key metrics, and run health checks'
+user_story: 'As a node operator, I want to monitor my Nitro node health and expose metrics'
+content_type: 'how-to'
+author: 'gzeoneth'
+sme: 'gzeoneth'
+---
+
+import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition/';
+
+Nitro exposes Prometheus-compatible metrics through a dedicated metrics server and reports health through per-binary mechanisms.
+
+## Metrics server
+
+### Enable the metrics server
+
+Pass the `--metrics` flag when starting the node. Configure the server with these flags:
+
+| Flag                               | Default     | Description                              |
+| ---------------------------------- | ----------- | ---------------------------------------- |
+| `--metrics-server.addr`            | `127.0.0.1` | Listen address for the metrics server    |
+| `--metrics-server.port`            | `6070`      | Listen port for the metrics server       |
+| `--metrics-server.update-interval` | `3s`        | How often internal metrics are refreshed |
+
+Example:
+
+```shell
+nitro --metrics \
+  --metrics-server.addr 0.0.0.0 \
+  --metrics-server.port 6070
+```
+
+### Prometheus scrape endpoint
+
+Once metrics are enabled, Nitro exposes a Prometheus-compatible endpoint at:
+
+```shell
+http://<metrics-server.addr>:<metrics-server.port>/debug/metrics/prometheus
+```
+
+`pprof` runs as a separate server at `/debug/pprof/` for CPU and memory profiling, enabled with `--pprof` and configured via `--pprof-cfg.addr` and `--pprof-cfg.port` (default 127.0.0.1:6071). It is not served on the metrics port.
+
+## Key metrics to monitor
+
+Group your alerts by concern. Metric names below are Nitro's Prometheus metric names.
+
+| Concern        | Metric                            | What it tells you                                                                                                                |
+| -------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| Memory         | `container_memory_rss`            | Actual container RSS. Alert on this, not Go heap — most Nitro memory is invisible to Go.                                         |
+| Sequencer feed | `arb_feed_backlog_messages`       | Messages in the feed backlog. A growing backlog means the node is falling behind the feed.                                       |
+| Sequencing     | `arb_sequencer_backlog`           | Backlog at the <a data-quicklook-from="sequencer">sequencer</a>. Sustained growth signals the sequencer can't keep up with load. |
+| Batch posting  | `arb_batchposter_wallet_eth`      | <a data-quicklook-from="batch-poster">Batch poster</a> wallet balance. Alert before it runs dry, or batches stop posting.        |
+| Batch posting  | `arb_batchposter_suggestedtipcap` | Suggested tip cap the batch poster is paying — tracks <a data-quicklook-from="parent-chain">parent-chain</a> fee pressure.       |
+| RPC protection | `arb_rpc_limitcheck_failure`      | Increments when an RPC call is rejected by the memory free-limit throttle (HTTP 429).                                            |
+
+<VanillaAdmonition type="tip">Always alert on `container_memory_rss`, not Go heap metrics. Most of Nitro's memory is invisible to Go's runtime — see [Memory allocators in Nitro](/run-arbitrum-node/nitro/node-tuning.mdx#memory-allocators-in-nitro).</VanillaAdmonition>
+
+## Health checks
+
+Nitro components expose health information through different mechanisms depending on the binary.
+
+### Main Nitro node
+
+The main `nitro` binary does not expose a dedicated `/health` endpoint. Node health is inferred from RPC availability: if the HTTP RPC port (default `8547`) responds with HTTP 200 to a valid JSON-RPC request, the node is healthy.
+
+Example liveness check:
+
+```shell
+curl -sf -X POST http://localhost:8547 \
+  -H "Content-Type: application/json" \
+  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
+```
+
+### Auxiliary components
+
+- **Transaction filterer**: Exposes a `/liveness` endpoint for health checks.
+- **DA server**: Exposes a `/health` endpoint.
+
+## Kubernetes
+
+If you run Nitro on Kubernetes, the community Helm chart wires up the `ServiceMonitor`, startup/liveness probes, and a Grafana dashboard for you. To learn how to enable metrics scraping and configure probes on Kubernetes, see [Enable monitoring](/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx#step-4-enable-monitoring) and [Probes](/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx#probes) in the Helm guide.