Lesson 6: Tracking Performance (Gas Usage, Uptime, and Reliability in Forta Bots)
Welcome to a critical checkpoint on the monk’s path.
By now, you’ve learned to observe transfers, decode event logs, and emit alerts. But in the real world of production monitoring, detection logic is only half the journey. The other half is resilience.
Today’s lesson focuses on how to build robust, efficient, and reliable bots by monitoring three essential dimensions:
Gas usage
Bot uptime
Execution performance
Why Performance Monitoring Is Non-Negotiable
In DevOps and security alike, a broken watcher is worse than no watcher at all. If your Forta bot:
Runs out of gas
Fails intermittently
Emits alerts too slowly
Or crashes under certain traces
...you lose visibility, and sometimes right when you need it most.
Forta runs your bot against thousands of live transactions per minute across multiple chains. Your agent must be lightweight, stable, and transparent in its own behavior.
1. Monitoring Gas Usage
Although Forta bots don’t directly pay gas (Forta nodes do), your bot consumes CPU and memory during its execution.
Each agent has a gas cost equivalent computed by Forta:
Bots that take longer to execute per tx are more expensive
If your bot consistently exceeds thresholds, it may be disabled or deprioritized
Tips to Reduce Gas Usage and CPU Cost
Avoid unnecessary loops
Don’t parse logs from every contract, better filter by address or topic first
Don’t decode more data than you need
Cache reused values (e.g. token decimals)
2. Monitoring Bot Uptime
You can track bot uptime on:
Forta Explorer --> Search your bot address --> View performance panel
Key metrics:
Uptime %
Number of transactions processed
Alert frequency
Average execution time per tx
Forta's backend automatically flags:
Bots that stop responding
Bots that error on certain tx types
Bots with consistently high execution time
3. Using handleBlock()
for Lightweight Monitoring
If your use case doesn’t require watching every transaction, consider using handleBlock()
.
Example:
function handleBlock(blockEvent) {
const findings = [];
if (blockEvent.blockNumber % 1000 === 0) {
findings.push(Finding.fromObject({
name: "Block Milestone",
description: "1,000 blocks passed",
alertId: "BLOCK-MILESTONE",
severity: FindingSeverity.Low,
type: FindingType.Info
}));
}
return findings;
}
Use this pattern to:
Emit periodic health signals
Check state at intervals (like total token supply)
Reduce computation pressure compared to per-transaction bots
4. Using Prometheus + Grafana with Forta
For advanced teams running their own scan nodes, it's possible to integrate Prometheus exporters to monitor:
Node health
Agent success/failure rate
Per-agent metrics: CPU, memory, tx processed
You can also configure alerting thresholds in Grafana dashboards to monitor:
Latency spikes
Error rate anomalies
Sudden drop in alert volume
This goes beyond the basic CLI setup, but it becomes essential when you need to scale.
Additional Diagnostic Tips
Add console logs (visible when testing locally)
Use try/catch to prevent agent crashes
Simulate edge cases: no logs, malformed logs, high tx throughput
Write fuzz tests that push random values into your bot logic
Checklist Before Publishing Any Forta Bot
Before publishing a bot make sure to:
npm run test
passes locallyHandles txs without logs gracefully
Doesn’t rely on external HTTP requests
Execution time per tx < 100ms
Alerts are rate-limited or aggregated if needed
Metadata fields are short and relevant
Verified on Forta Explorer under expected chains
Example Project to test
detect-large-usdc-transfer-agent
Key Concepts Recap
As a Forta Administrator, you are not just building detectors, you are maintaining critical security infrastructure.
Bots that fail silently become blind spots in your organization’s threat detection system.
Mastering gas optimization, uptime monitoring, and performance testing is what turns a good bot into a trusted security asset.
Next lesson, we will explore how to route alerts into systems like Slack, Telegram, or PagerDuty, and set up a true real-time on-call response pipeline.
Until next meditation,
The Blockchain Security Monk