Skip to content
OnchainProbe Docs

FAQ

What does OnchainProbe test?

Section titled “What does OnchainProbe test?”

OnchainProbe tests blockchain RPC endpoints using synthetic suites for correctness, consistency, and latency. It does not host nodes or replace full observability stacks.

How do I compare two providers or clients?

Section titled “How do I compare two providers or clients?”

Add at least two endpoints to one chain, configure a comparison-capable suite, set one endpoint as reference, and review run verdicts.

What does warn verdict mean?

Section titled “What does warn verdict mean?”

warn indicates a check is approaching its threshold (above 90%) but has not crossed it. It should be triaged, but it does not block CI (exit_code remains 0). Only fail produces exit_code: 1.

How do I fail CI when suites fail?

Section titled “How do I fail CI when suites fail?”

Trigger a run and then read /runs/:runId/verdict. Use exit_code as the CI process exit code.

Why are block-based runs not firing?

Section titled “Why are block-based runs not firing?”

Common causes:

  • observer is unhealthy
  • all relevant endpoints are disabled or auto-disabled
  • suite was auto-disabled after 3 consecutive no-target evaluations

Check endpoint and suite status, then re-enable after fixing root cause.

Why was my endpoint auto-disabled?

Section titled “Why was my endpoint auto-disabled?”

The block observer auto-disables endpoints after 24 hours of continuous connection or RPC failures. A successful block fetch during that window resets the timer, but once disabled, you must re-enable manually from endpoint actions or the API.

Why was my suite auto-disabled?

Section titled “Why was my suite auto-disabled?”

If a suite fails to find valid targets (endpoints) for 3 consecutive scheduler evaluations, it is automatically disabled. Common causes: all matched endpoints were deleted, tag selectors match nothing, or targets are misconfigured. The suite’s disabled_reason field contains a breakdown of what failed. Fix the target configuration and re-enable the suite.

Can I test private/authenticated RPC endpoints?

Section titled “Can I test private/authenticated RPC endpoints?”

Yes. Endpoint configuration supports authentication types: basic, bearer_token, header, and query_param. Keep credentials in secure secret storage and rotate when needed.

Are API keys available on all plans?

Section titled “Are API keys available on all plans?”

API keys are available on Pro and above. Use scoped keys for CI and automation.

What data can be shown publicly?

Section titled “What data can be shown publicly?”

Public dashboards can share selected endpoint/suite performance metrics without exposing endpoint credentials or private tenant configuration.

Can I run transaction-based suites?

Section titled “Can I run transaction-based suites?”

Yes, with wallet pools (Pro). Configure wallet roles and funding policy before enabling suites that send transactions.

Do I need to install an agent on my nodes?

Section titled “Do I need to install an agent on my nodes?”

No. OnchainProbe calls your configured RPC endpoints over the network. No node-side agent is required for basic suite execution.

Does OnchainProbe replace Prometheus/Grafana?

Section titled “Does OnchainProbe replace Prometheus/Grafana?”

No. OnchainProbe focuses on synthetic RPC regression testing and comparison workflows. Keep your infrastructure observability stack for host/resource telemetry.

Can I keep some suites manual only?

Section titled “Can I keep some suites manual only?”

Yes. Set schedule_type to manual. The suite will only run when triggered via UI or API.

What verdict checks are there?

Section titled “What verdict checks are there?”

Four independent checks. The overall verdict is the worst status across all:

  • latency_p95: absolute p95 latency vs threshold (always runs)
  • latency_vs_reference: candidate p95 vs reference p95 (when reference endpoint exists)
  • correctness: response match rate (when reference exists and correctness is enabled)
  • latency_vs_baseline: candidate p95 vs previous baseline run (when baseline exists)

See Comparisons for details on each check.

How do acknowledgements work?

Section titled “How do acknowledgements work?”

Acknowledgements let you mark known-benign failures so they stop affecting run verdicts. Create rules that match specific checks, endpoints, and error patterns. On future runs, matched failures are flagged as acknowledged and no longer count toward the failure tally. If all failures on a target are acknowledged, that target is promoted to success.

New acknowledgement rules only apply to future runs. See Acknowledgements.

How do I reduce noisy failures?

Section titled “How do I reduce noisy failures?”
  • increase interval for heavy suites
  • split suites by purpose (correctness vs performance)
  • isolate unstable endpoints into separate canary suites
  • tune thresholds based on baseline runs

What should I include in an incident report?

Section titled “What should I include in an incident report?”
  • chain and suite ID
  • affected endpoints and tags
  • run IDs with timestamps
  • verdict summary and sample errors
  • mitigation/rollback actions taken

How do soft deletes work?

Section titled “How do soft deletes work?”

Chains, endpoints, and suites support soft delete and restore endpoints in API. Historical run data remains available unless separately pruned by platform policy.

How do I migrate from manual checks to continuous testing?

Section titled “How do I migrate from manual checks to continuous testing?”
  1. Create one smoke suite in manual mode.
  2. Validate first run output.
  3. Move to interval scheduling.
  4. Add alerting.
  5. Integrate CI gating.

Troubleshooting quick checklist

Section titled “Troubleshooting quick checklist”
  • run connectivity check for each endpoint
  • confirm suite parameters are valid for the chain
  • inspect /runs/:runId/samples for failing methods
  • check /runs/:runId/verdict summary for comparison context
Section titled “Related”