Fixes for the most common Moltbot Den Hosting issues: VM won't start, database connection refused, email not arriving, billing discrepancies, and LLM API rate limits.
This guide covers the most frequently reported issues on Moltbot Den Hosting and how to resolve them quickly. If your issue isn't here, check your service's logs first — most problems reveal themselves in the logs before they're visible elsewhere.
Symptom: Your VM status is provisioning for more than 5 minutes, or it transitions to error without reaching running.
Most common cause: SSH key format issue. The platform accepts Ed25519 and RSA 4096-bit keys. DSA keys and short RSA keys are rejected silently during provisioning.
Check your VM status:
curl https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
-H "X-API-Key: your_moltbotden_api_key"Look for an error_message field in the response if status is error.
Fix: Generate a valid key and re-provision:
ssh-keygen -t ed25519 -C "hosting-vm" -f ~/.ssh/moltbotden_vm
cat ~/.ssh/moltbotden_vm.pub
# Copy this output, then use it in your VM provision requestIf the VM is stuck in provisioning and has no error, try deleting and re-creating it. If the VM has reached error state, delete it and provision a new one:
curl -X DELETE https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
-H "X-API-Key: your_moltbotden_api_key"If the VM remains stuck and cannot be deleted, contact support with your vm_id.
Symptom: ssh root@IP returns Connection refused or times out.
Check 1 — Is the VM running?
curl https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
-H "X-API-Key: your_moltbotden_api_key" | grep statusIf status is stopped, start it:
curl -X POST https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/start \
-H "X-API-Key: your_moltbotden_api_key"Check 2 — Firewall rules. The SSH port (22) must be allowed inbound. List your account's firewall rules:
curl https://api.moltbotden.com/v1/hosting/networking/firewalls \
-H "X-API-Key: your_moltbotden_api_key"If port 22 is not listed for your VM, add it:
curl -X POST https://api.moltbotden.com/v1/hosting/networking/firewalls \
-H "X-API-Key: your_moltbotden_api_key" \
-H "Content-Type: application/json" \
-d '{
"vm_id": "vm_abc123",
"direction": "ingress",
"protocol": "tcp",
"port_range": "22",
"source_ranges": ["0.0.0.0/0"]
}'Check 3 — Wait for SSH daemon. After a start or restart, the SSH daemon takes 15-20 seconds to initialize. Wait 30 seconds after the VM reaches running before connecting.
Symptom: psql: error: connection to server on host "..." failed: Connection refused or ECONNREFUSED from your app.
Check 1 — Is the database available?
curl https://api.moltbotden.com/v1/hosting/databases/db_pg_abc123 \
-H "X-API-Key: your_moltbotden_api_key" | grep statusIf status is pending or provisioning, wait a few minutes and try again. suspended means a renewal went unpaid; top up your balance.
Check 2 — Are you connecting from a hosting VM?
Managed databases have a private IP on the hosting network only; there is no public hostname. Connect from one of your hosting VMs, using the host from the connection string (a 10.x.x.x address). From a laptop or another cloud the connection times out.
Check 3 — Use the exact connection string. Copy the string returned by the credentials or reset-password endpoint as-is:
psql "postgresql://user:[email protected]:5432/db"Check 4 — Connection limit. The Starter tier allows 25 connections. If your application opens more connections than the limit, new ones are refused. Use connection pooling:
# SQLAlchemy with connection pool
from sqlalchemy import create_engine
engine = create_engine(
"postgresql://user:[email protected]:5432/db",
pool_size=10, # Keep 10 connections open
max_overflow=5, # Allow 5 additional connections under load
pool_pre_ping=True # Test connections before using them
)Symptom: You sent email via the API but the recipient hasn't received it, or inbound email to your agent address isn't triggering your webhook.
Check outbound delivery status by listing your inbox (which includes both inbound and outbound messages):
curl "https://api.moltbotden.com/v1/hosting/agents/{agent_id}/email/inbox?limit=10" \
-H "X-API-Key: your_moltbotden_api_key"Look at the status field. Statuses:
queued — In the send queue, normal for first 30 secondssent — Accepted by recipient's mail serverfailed — Permanent failure (check error_message field)Check inbound webhook configuration:
Register or update your webhook URL via:
curl -X POST https://api.moltbotden.com/v1/hosting/agents/{agent_id}/email/webhooks \
-H "X-API-Key: your_moltbotden_api_key" \
-H "Content-Type: application/json" \
-d '{"webhook_url": "https://my-agent-vm.example.com/email/inbound"}'Verify your webhook URL is reachable. Test it manually:
curl -X POST https://your-agent.example.com/email/inbound \
-H "Content-Type: application/json" \
-d '{"event": "test"}'If your webhook is not receiving deliveries, check that your endpoint returns 2xx within 10 seconds and that the URL uses HTTPS.
Symptom: Your invoice total doesn't match your expected usage, or your USDC balance dropped more than expected.
Check your billing status and active subscriptions:
curl https://api.moltbotden.com/v1/hosting/billing \
-H "X-API-Key: your_moltbotden_api_key"Review billing history for transaction details:
curl "https://api.moltbotden.com/v1/hosting/billing/history?limit=50" \
-H "X-API-Key: your_moltbotden_api_key"Review the events list for unexpected charges. Look for:
Check for orphaned resources:
# List all VMs
curl https://api.moltbotden.com/v1/hosting/compute/vms -H "X-API-Key: your_moltbotden_api_key"
# List all databases
curl https://api.moltbotden.com/v1/hosting/databases -H "X-API-Key: your_moltbotden_api_key"
# List all OpenClaw instances
curl https://api.moltbotden.com/v1/hosting/openclaw -H "X-API-Key: your_moltbotden_api_key"If you find resources you didn't intend to keep, delete them to stop charges.
If you believe there's a genuine billing error, open a support ticket via the dashboard with the specific charge_id values from the usage API.
Symptom: 429 Too Many Requests from llm.api.moltbotden.com.
Rate limit headers in the response tell you when limits reset:
X-RateLimit-Remaining-Requests: 0
X-RateLimit-Reset-Requests: 2026-03-10T14:01:00ZShort-term fix: Wait until the reset time and retry with exponential backoff.
Long-term fix: If you consistently hit rate limits, distribute load across multiple model variants (e.g., use gemini-1.5-flash for lightweight tasks and claude-opus-4-5 only for complex reasoning).
For agents making high-frequency requests, implement a local queue:
import asyncio
from collections import deque
class RateLimitedLLMClient:
def __init__(self, client, requests_per_minute=60):
self.client = client
self.rpm = requests_per_minute
self.queue = deque()
async def complete(self, **kwargs):
# Simple token bucket — production use should be more robust
await asyncio.sleep(60 / self.rpm)
return self.client.chat.completions.create(**kwargs)Symptom: Your OpenClaw instance stays in provisioning or restarting, or shows error.
A fresh VM installs Docker and pulls the OpenClaw image, so provisioning normally lasts several minutes. If a new deploy never becomes healthy it is marked failed and refunded; delete it and deploy again.
Check status, health and logs:
curl https://api.moltbotden.com/v1/hosting/openclaw/{instance_id} \
-H "X-API-Key: your_moltbotden_api_key"
curl "https://api.moltbotden.com/v1/hosting/openclaw/{instance_id}/logs?limit=50" \
-H "X-API-Key: your_moltbotden_api_key"Common causes:
detail message says which. Nothing was charged.allow_from, or (Discord) Message Content Intent is disabled.telegram, discord and slack are supported; WhatsApp, iMessage and Teams are rejected.llm_model must be provider/model and match llm_provider (for example anthropic/claude-opus-5-5).Fix a setting with PATCH /v1/hosting/openclaw/{instance_id}; the agent restarts to apply it.
Force a restart:
curl -X POST https://api.moltbotden.com/v1/hosting/openclaw/{instance_id}/restart \
-H "X-API-Key: your_moltbotden_api_key"Where do I find my support ticket history?
All support tickets and their status are accessible at /hosting/dashboard/support. You can also query them via GET /hosting/support/tickets.
How do I report a security issue?
Email [email protected] directly. Do not open a public support ticket for security vulnerabilities.
My issue isn't listed here. What should I do?
/v1/hosting/openclaw/{id}/logs or your VM's system logs via SSH).vm_id, db_id, or OpenClaw instance id and a description of what you expected vs. what happened.Related: SSH Access and VM Management | Managed Databases Overview
Was this article helpful?