SLI (Service Level Indicator)

An SLI is a direct, numerical measurement of a specific aspect of service performance. It answers the question "How is the service performing?" with a hard number, not a subjective opinion.

Examples include:

• Latency: The time to complete a request (e.g., 150ms for an RPC call).
• Availability: The percentage of successful requests (e.g., 99.95% uptime).
• Throughput: The number of requests processed per second.
• Error Rate: The percentage of requests that fail.

A valid SLI measures performance from the end-user's point of view, not from internal system metrics. It reflects the actual experience of a client, dApp, or downstream service.

For blockchain infrastructure:

• A node's block propagation time is an SLI for a validator.
• An RPC endpoint's success rate for eth_getBalance is an SLI for a wallet user.
• Finality time is an SLI for an exchange confirming deposits. Internal metrics like CPU usage are important but are not SLIs.

An SLI's primary purpose is to be compared against a Service Level Objective (SLO), which is a target value or range for the SLI. The SLO defines what "good" performance looks like.

Example Relationship:

• SLI: Average RPC request latency.
• SLO: 95% of requests complete in < 200ms over a 30-day window.
• Outcome: The SLI data is continuously measured to determine if the SLO is being met, triggering alerts or remediation if breached.

SLIs are not instantaneous snapshots; they are aggregated over a defined time window (e.g., 1 minute, 1 hour, 30 days). This provides a stable, meaningful view of performance trends and prevents overreacting to brief anomalies.

Common aggregation methods include:

• Rolling averages (e.g., average latency over the last 5 minutes).
• Percentiles (e.g., 95th percentile latency).
• Rate calculations (e.g., errors per second).
• Proportions (e.g., successful requests / total requests over a day).

A good SLI has a clear, unambiguous definition that specifies exactly what is being measured, how it's measured, and from where. This eliminates confusion and ensures consistent monitoring.

Well-defined SLI Example: "The proportion of successful JSON-RPC calls to the eth_blockNumber method, as measured from three global health-check agents, aggregated as a rolling 1-minute average, excluding client-side timeouts."

A poorly defined SLI would be simply "node health."

The data from an SLI must be actionable for the engineering team responsible for the service. It should directly point to areas of the system that need investigation or improvement when performance degrades.

• A spike in RPC error rate SLI can trigger database connection pool checks.
• An increase in consensus latency SLI can lead to peer connectivity analysis.
• By tracking SLIs, teams can make data-driven decisions about capacity planning, bug fixes, and infrastructure changes.

The percentage of time a node is online and able to participate in the network. This is a foundational SLI for any node operator.

• Measured as: (Total Time - Downtime) / Total Time.
• Example: A node with 99.5% uptime over a month was unavailable for approximately 3.6 hours.
• Impact: Low uptime can lead to missed blocks, transaction delays, and reduced network health.

The time it takes for a newly mined or validated block to be received by a node after it is created. This measures network synchronization speed.

• Measured as: The P95 or P99 latency in milliseconds from block creation to reception.
• Example: A target SLI might be P95 block propagation < 2 seconds.
• Impact: High latency can cause forks, stale blocks, and consensus instability.

The rate at which a node can process and relay transactions, often measured in transactions per second (TPS).

• Measured as: Number of transactions processed / Time period.
• Example: A node's mempool might have an SLI for processing incoming transactions with a throughput of > 1000 TPS.
• Impact: Limits the node's ability to handle network load and can become a bottleneck.

The number of stable, active peer-to-peer connections a node maintains and the quality of those connections.

• Measured as: Count of established peers and metrics like connection churn rate or peer latency.
• Example: An SLI could be maintain > 50 stable peer connections with a churn rate of < 5% per hour.
• Impact: Critical for data redundancy, network gossip efficiency, and resilience against eclipse attacks.

The latency for a node's RPC or REST API to respond to client queries, such as requests for block data or account balances.

• Measured as: P95 latency for key endpoint groups (e.g., eth_getBlockByNumber, cosmos/staking/validators).
• Example: An SLI target might be P95 API response time < 100ms for read queries.
• Impact: Directly affects the experience of dApps, wallets, and explorers relying on the node.

Metrics tracking the consumption of hardware resources by the node software, indicating performance limits and health.

• Key SLIs: CPU usage (%), Memory usage (GB), Disk I/O latency (ms), and Network bandwidth (MB/s).
• Example: Setting an SLI for CPU usage < 80% under normal load to ensure headroom for spikes.
• Impact: High utilization can lead to node crashes, slow synchronization, and missed blocks.

Effective SLIs measure what matters to the end-user. Avoid vanity metrics in favor of user-centric signals. For blockchain services, this typically means focusing on:

• Availability: Can users submit transactions? (e.g., RPC endpoint uptime)
• Latency: How long do operations take? (e.g., time-to-finality, block propagation time)
• Correctness: Are operations executed accurately? (e.g., transaction success rate, state consistency)
• Throughput: What is the system's capacity? (e.g., transactions per second the network can handle).

An SLI becomes operational when paired with a Service Level Objective (SLO)—a target threshold for the metric. The error budget is the allowable amount of service degradation (100% - SLO).

• Example: If API availability SLO is 99.9%, the monthly error budget is ~43 minutes of downtime.
• This budget guides development priorities: burning through it triggers a focus on reliability; a surplus allows for deploying new features with higher risk.

SLIs require reliable, low-overhead telemetry. Implementation involves:

• Probing vs. Sampling: Use synthetic probes (active checks) for availability and request sampling (passive observation of real traffic) for latency/errors.
• Metric Aggregation: SLIs are often defined as a ratio (e.g., successful requests / total requests) over a rolling window.
• Cardinality Management: Avoid high-cardinality labels (like per-user metrics) for core SLIs to keep query performance and costs manageable.

Implementing SLIs for decentralized systems introduces unique complexities:

• Node Diversity: Metrics must account for variations across different client implementations (e.g., Geth vs. Nethermind).
• Network Layers: Separate SLIs for consensus layer (block production) and execution layer (transaction processing).
• Finality vs. Liveness: Distinguish between soft confirmations and probabilistic vs. absolute finality.
• MEV & Congestion: User experience can degrade due to maximal extractable value (MEV) and mempool congestion, which are external to base protocol SLIs.

Traditional alerts on low-level symptoms (high CPU, memory) create noise. SLI-based alerting focuses on user impact.

• Burn-Rate Alerts: Trigger alerts based on the rate the error budget is being consumed (e.g., "burning error budget 5x faster than allowed").
• Multi-Window Alerting: Combine short (e.g., 5-min) and long (e.g., 30-day) windows to catch both sudden outages and chronic degradation.
• Avoid alerting directly on SLO breaches; use the error budget as a buffer to enable automated responses.

These are the fundamental performance metrics for any blockchain node or network.

• Block Production Latency: Time between consecutive blocks.
• Transaction Finality Time: Time for a transaction to become irreversible.
• Node Uptime: Percentage of time a validator or RPC endpoint is reachable.
• Peer Count: Number of active connections to other network participants.
• Sync Status: Measure of how far a node is from the chain tip.

Metrics for the interfaces that dApps and users interact with, crucial for developer experience.

• Request Success Rate: Percentage of successful API calls (e.g., eth_getBalance).
• Request Latency (P95/P99): The latency for the slowest 5% or 1% of requests.
• Concurrent Connections: Number of simultaneous active WebSocket or HTTP connections.
• Error Rate by Method: Breakdown of failures for specific JSON-RPC methods.

Application-layer indicators that measure the health of decentralized applications.

• Transaction Success Rate: Percentage of user transactions that succeed on-chain.
• Gas Estimation Accuracy: How closely estimated gas matches actual gas used.
• Contract Call Latency: Time from user signing to on-chain confirmation for specific functions.
• State Read Latency: Time to query contract state via an indexer or subgraph.

Metrics specific to Proof-of-Stake (PoS) and other consensus participants, essential for network security.

• Proposal Success Rate: Percentage of times a validator successfully proposes a block when selected.
• Attestation Effectiveness: Timeliness and correctness of a validator's votes in committees.
• Slashing Events: Count of penalties incurred for malicious or faulty behavior.
• Effective Balance Health: Monitoring of staked ETH or other assets relative to activation thresholds.

Indicators for interoperability protocols, where reliability is paramount for asset security.

• Bridge Finality Time: Time for an asset to be usable on the destination chain.
• Message Relay Success Rate: Percentage of cross-chain messages delivered successfully.
• Watchdog Health: Status of fraud detection and challenge mechanisms.
• Liquidity Provider Balance: Available liquidity for instant withdrawals on the destination chain.