A comprehensive real-time monitoring system for the Flux blockchain network that tracks cloud utilization, revenue metrics, node distribution, gaming applications, and cryptocurrency nodes.
The Flux Performance Dashboard provides live insights into the Flux decentralized cloud computing network. It monitors resource utilization across the network, tracks revenue streams from the Flux blockchain, and displays running applications including gaming servers and crypto nodes. The dashboard features historical analytics with customizable comparison periods (day, week, month, quarter, year) and a scrolling carousel showcasing top-performing applications.
- CPU: Total and used CPU cores across the network with utilization percentage
- RAM: Total and used memory (GB) with utilization percentage
- Storage: Total and used disk space (GB) with utilization percentage
- Daily Revenue: FLUX earned from network operations
- Transaction History: Detailed record of all revenue transactions with block heights, addresses, and timestamps
- Payment Counts: Number of transactions per period
- USD Conversion: Real-time FLUX price and USD equivalents
- Cumulus: Entry-level nodes (2 cores, 8GB RAM, 220GB storage)
- Nimbus: Mid-tier nodes (4 cores, 32GB RAM, 440GB storage)
- Stratus: Premium nodes (8 cores, 64GB RAM, 880GB storage)
- Total Nodes: Aggregate count across all tiers
- Minecraft: Server instances running on Flux
- Palworld: Multiplayer server instances
- Enshrouded: Game server instances
- Total Gaming Apps: Combined count of all gaming applications
- Presearch: Decentralized search engine nodes
- Kaspa: Kaspa blockchain full nodes
- Alephium: Alephium blockchain nodes
- Ravencoin: RVN full nodes
- Kadena: Kadena blockchain nodes
- Streamr: Decentralized data streaming nodes
- Bittensor: AI/ML network nodes
- Timpi: Privacy-focused search nodes (Collector & Geocore)
- Total Crypto Nodes: Aggregate of all cryptocurrency nodes
- WordPress Instances: Total WordPress sites hosted on Flux
- Watchtower Apps: Network monitoring applications
- Total Apps: All applications running across the network
-
Revenue Sync: Every 5 minutes via Blockbook API
- Fetches latest transactions from Flux blockchain
- Incremental sync from last known block height
- Filters existing transactions to avoid duplicates (99%+ efficiency)
-
Service Health Checks: Every 60 minutes
- Tests all gaming services for availability
- Validates crypto node endpoints
- Checks API health and response times
-
Carousel Updates: Every 60 minutes
- Refreshes top running applications
- Updates benchmark statistics
- Caches data for 1-hour resilience during API failures
- Dashboard Auto-Refresh: Every 5 minutes (300 seconds)
- Current metrics update
- Revenue data refresh
- Comparison statistics recalculation
The system automatically captures complete network state snapshots every day:
- Timing: Taken daily after midnight UTC with 5-minute grace period
- Frequency Check: System verifies snapshot exists every 30 minutes
- Automatic Retry: If snapshot missing, system attempts to create one
Each daily snapshot includes:
- Complete revenue metrics for the day
- Cloud utilization statistics (CPU, RAM, Storage)
- Node distribution across all tiers
- Gaming application counts
- Cryptocurrency node counts
- WordPress and app totals
- Timestamp and date metadata
- Snapshots: Retained indefinitely for historical analysis
- Transactions: 365 days (configurable retention policy)
Administrators can trigger manual snapshots via API:
POST /api/admin/snapshotThe dashboard compares current metrics against historical snapshots to show trends and changes over time.
Users can toggle between five comparison timeframes:
| Period | Label | Days | Comparison Point |
|---|---|---|---|
| D | Day | 1 | Yesterday's snapshot |
| W | Week | 7 | Snapshot from 7 days ago |
| M | Month | 30 | Snapshot from 30 days ago |
| Q | Quarter | 90 | Snapshot from 90 days ago |
| Y | Year | 365 | Snapshot from 365 days ago |
For each metric, the system calculates:
- Absolute Change:
Current Value - Historical Value - Percentage Change:
((Current - Historical) / Historical) Γ 100 - Trend Direction:
upif current > historicaldownif current < historicalneutralif unchanged
Current State (Today):
- Cumulus: 10,500 nodes
- Nimbus: 5,200 nodes
- Stratus: 1,800 nodes
- Total: 17,500 nodes
Historical Snapshot (7 days ago):
- Cumulus: 10,200 nodes
- Nimbus: 5,150 nodes
- Stratus: 1,750 nodes
- Total: 17,100 nodes
Comparison Results:
{
cumulus: {
change: +300, // 10,500 - 10,200
percentage: +2.94%, // (300 / 10,200) Γ 100
trend: 'up'
},
nimbus: {
change: +50, // 5,200 - 5,150
percentage: +0.97%, // (50 / 5,150) Γ 100
trend: 'up'
},
stratus: {
change: +50, // 1,800 - 1,750
percentage: +2.86%, // (50 / 1,750) Γ 100
trend: 'up'
},
total: {
change: +400, // 17,500 - 17,100
percentage: +2.34%, // (400 / 17,100) Γ 100
trend: 'up'
}
}Revenue comparisons work differently because they use transaction aggregation rather than snapshots:
Example: Monthly Revenue Comparison
Current Month (Nov 1-21):
- Total FLUX earned: 45,230
- USD value: $6,784.50
- Transactions: 1,247
Previous Month (Oct 1-31):
- Total FLUX earned: 42,100
- USD value: $6,315.00
- Transactions: 1,189
Comparison:
{
flux: {
amount: 45230,
change: +7.44%, // ((45,230 - 42,100) / 42,100) Γ 100
trend: 'up'
},
payments: {
count: 1247,
change: +58, // 1,247 - 1,189
trend: 'up'
}
}To improve performance:
- Comparisons are cached per period when first loaded
- Cache is automatically refreshed during dashboard auto-refresh (every 5 minutes)
- All five periods are prefetched in background after initial page load
- Manual refresh available via period toggle buttons
If a historical snapshot doesn't exist for the requested comparison period:
- System returns
partialData: trueflag - Revenue comparison still works (uses transaction aggregation)
- Other metrics show as unavailable for that period
- Dashboard displays appropriate messaging to user
- RESTful API endpoints for metrics, snapshots, and analytics
- SQLite database with WAL mode for concurrent access
- Automated schedulers for revenue sync and snapshot management
- Blockbook API integration for blockchain data
- CORS enabled for domain and IP access
- Reactive components with real-time updates
- Chart.js integration for historical analytics
- Responsive design with terminal-style aesthetics
- Purple-themed UI matching Flux branding
- Carousel component with automatic scrolling
- daily_snapshots: Historical network state records
- revenue_transactions: Complete transaction history with blockchain data
- current_metrics: Real-time network statistics
- sync_status: Synchronization state tracking
- Node.js 18+
- npm or yarn
# Install dependencies
npm install
# Start development server
npm run dev
# Build for production
npm run build
# Preview production build
npm run preview# Start Express API server (default port 3000)
node server.jsThe backend will automatically:
- Initialize SQLite database
- Start revenue sync scheduler (every 5 minutes)
- Start snapshot checker (every 30 minutes)
- Start service test scheduler (every hour)
- Start carousel update scheduler (every hour)
The system supports both IP address and domain access. Update CORS settings in server.js:
const corsOptions = {
origin: [
'http://localhost:5173', // Development
'http://your-ip:37000', // Production IP
'http://your-domain.app.runonflux.io', // Production Domain
]
};GET /api/health- System health check with snapshot statusGET /api/metrics/current- Current network metricsGET /api/stats- Full statistics including revenueGET /api/analytics/comparison?period=D|W|M|Q|Y- Period comparisons
GET /api/revenue/transactions?page=1&limit=50- Paginated transaction historyGET /api/revenue/daily?days=30- Daily revenue aggregation
GET /api/history/snapshots?limit=30- Recent snapshotsGET /api/history/range?start=YYYY-MM-DD&end=YYYY-MM-DD- Date range query
GET /api/admin/revenue-status- Revenue sync scheduler health and transaction countGET /api/admin/snapshot-status- Snapshot system healthGET /api/admin/test-status- Service test scheduler statusPOST /api/admin/revenue-sync- Trigger manual revenue syncPOST /api/admin/reset-revenue-sync- Reset sync block pointer (triggers full history re-scan next cycle)POST /api/admin/clear-revenue-data- Destructive β wipe all transactions and force full resyncPOST /api/admin/backfill-app-names- Backfill missing app names for transactions withapp_name = NULLPOST /api/admin/backfill-app-types- Backfill missing app types (git/docker) for known app namesPOST /api/admin/backfill- Regenerate daily snapshots from transaction data (last 365 days)POST /api/admin/snapshot- Trigger manual daily snapshotPOST /api/admin/test-services- Manually trigger service health tests
GET /api/carousel/stats- Top running applications with caching
- Real-time Monitoring: Live metrics updating every 5 minutes
- Historical Analytics: Interactive charts showing trends over time
- Flexible Comparisons: Compare against D/W/M/Q/Y time periods
- Transaction Browser: Searchable, paginated revenue transaction history
- Carousel Display: Rotating showcase of top applications and benchmarks
- Responsive Design: Mobile-friendly interface
- Terminal Aesthetics: Developer-friendly UI with purple Flux theming
- Auto-Recovery: Resilient schedulers with failure detection
- Data Validation: Snapshot verification before storage
- Efficient Syncing: Incremental blockchain sync minimizes API calls
# Backup database
cp data/flux-performance.db data/flux-performance.db.backup
# Check integrity
sqlite3 data/flux-performance.db "PRAGMA integrity_check;"Replace YOUR_SERVER with the actual host (e.g. 192.168.10.30:5173 for prod, localhost:5173 locally).
# Revenue sync health β last run time, in-progress flag, transaction count
curl http://YOUR_SERVER/api/admin/revenue-status
# Snapshot system health
curl http://YOUR_SERVER/api/admin/snapshot-statusRuns the same sync as the automatic 5-minute cycle immediately.
curl -X POST http://YOUR_SERVER/api/admin/revenue-syncTransactions are saved as soon as they appear on-chain. If the permanentmessages API hasn't indexed the app yet at that moment, the transaction lands with app_name = NULL. This endpoint re-fetches those transactions and resolves the name.
The auto-sync already handles recent rows (last 30 days, 100 per cycle). Use this endpoint to process a large backlog or historical data. Run multiple times until remaining reaches 0 or stops decreasing.
Transactions with no OP_RETURN (direct FLUX payments, not app payments) will stay NULL β that is correct behaviour and they are counted as noHash in the response.
# Default batch (500 rows, all NULL rows regardless of age)
curl -X POST http://YOUR_SERVER/api/admin/backfill-app-names \
-H "Content-Type: application/json"
# Larger batch to clear a backlog faster (max 2000 per call)
curl -X POST http://YOUR_SERVER/api/admin/backfill-app-names \
-H "Content-Type: application/json" \
-d '{"batchSize": 2000}'Fills in app_type for transactions that have an app_name but no type yet. Safe to run any time.
curl -X POST http://YOUR_SERVER/api/admin/backfill-app-typesRegenerates daily snapshot records from existing transaction data for the past 365 days. Use if snapshot history has gaps.
curl -X POST http://YOUR_SERVER/api/admin/backfillCreates a daily snapshot for today using current metrics.
curl -X POST http://YOUR_SERVER/api/admin/snapshotClears the last-synced block pointer so the next cycle re-scans from the configured lookback window. Does not delete any data β it just forces a wider scan next time. Use if you suspect gaps in transaction history.
curl -X POST http://YOUR_SERVER/api/admin/reset-revenue-sync
# Then trigger an immediate sync to kick it off now
curl -X POST http://YOUR_SERVER/api/admin/revenue-syncDeletes every revenue transaction and resets sync state to zero. The next sync cycle re-imports all history. Use only as a last resort (corrupted data, clean-slate needed).
curl -X POST http://YOUR_SERVER/api/admin/clear-revenue-data- Check
/api/healthfor overall system status - Monitor console logs for sync failures (3+ consecutive = alert)
- Verify daily snapshots exist via
/api/admin/snapshot-status
Logging can be configured in server.js:
const LOGGING_CONFIG = {
enableRequestLogging: true, // Master switch
logHealthChecks: false, // Skip /health endpoints
logStatsEndpoints: false, // Skip /stats endpoints
logMetricsEndpoints: false, // Skip /metrics endpoints
logComparisonEndpoints: false, // Skip /comparison endpoints
logHistoryEndpoints: true, // Log history queries
logAdminEndpoints: true, // Always log admin actions
logErrorsOnly: false // Only log errors (overrides above)
};- Check snapshot status:
GET /api/admin/snapshot-status - Verify snapshot checker is running (should log every 30 minutes)
- Check for validation failures in logs
- Ensure metrics are available from external APIs
- Check revenue status:
GET /api/admin/revenue-status - Verify Blockbook API is accessible
- Check for consecutive failures (3+ indicates problem)
- Review last synced block height
- Verify historical snapshots exist for requested period
- Check if snapshot exists for target date:
GET /api/history/snapshot/{date} - Revenue comparisons should still work (uses transactions)
- Consider running backfill if snapshots are missing
This project is built for monitoring the Flux blockchain network.
- Flux blockchain network and APIs
- Blockbook blockchain explorer
- SvelteKit framework
- Chart.js visualization library