Verify Everything

Run through these checks to confirm each component is working correctly.

Health Checks

# 1. L2 Node — should return JSON with node status
curl -s http://127.0.0.1:41721/api/v1/health

# 2. IPFS — should return peer ID and addresses
curl -s http://127.0.0.1:5001/api/v0/id | python3 -m json.tool

# 3. Push Gateway — should return status
curl -s http://127.0.0.1:41722/health

# 4. Web Frontend — should return the HTML page
curl -s -o /dev/null -w "%{http_code}" https://node.yourdomain.com/app/

# 5. API via reverse proxy — should match direct L2 node response
curl -s https://node.yourdomain.com/api/v1/health

# 6. WebSocket — should return 101 (Switching Protocols)
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==" \
  -H "Sec-WebSocket-Version: 13" \
  https://node.yourdomain.com/api/v1/ws
# Expect 101. If you get 200/400/426/502, the WebSocket upgrade is NOT being
# proxied — the upgrade must bypass the generic /api/ proxy (Apache: WS
# RewriteRule first + "ProxyPass /api/v1/ws !"). Live DM/notification delivery
# depends on this. See the Reverse Proxy tutorial.

Service Status

# Check all services at once
sudo systemctl status ogmara-node ipfs ogmara-push-gateway nginx

# Or for Docker deployments
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Expected Resource Usage

Under normal operation with all components running, expect approximately:

• CPU: 5–15% idle, spikes during message bursts or IPFS operations
• RAM: 200–500 MB total across all services
• Disk: Grows with messages and pinned IPFS content; monitor with df -h
• Network: Depends on peer count and message volume; P2P traffic on port 41720

Monitoring Logs

Keep an eye on logs during the first few hours of operation to catch any issues early.

# Follow all Ogmara logs
sudo journalctl -u ogmara-l2 -u ogmara-push -u ipfs -f

# Check for errors only
sudo journalctl -u ogmara-l2 -p err --since "1 hour ago"