Always On – Lacking an Automatic Suspension Threshold

No native automatic suspension for Always On Repls

Confirmed: Replit does not currently provide a native configuration flag, API endpoint, or webhook that automatically toggles the "Always On" status based on CPU usage, request volume, or idle time. Always On is designed to keep a Repl active regardless of traffic and is enabled or disabled manually in the UI. Replit does not publish a minimum traffic threshold for keeping a Repl Always On, and cost is tied to subscription tier rather than granular usage cycles.

What is confirmed vs likely

Confirmed facts from current documentation: Always On requires manual enable/disable. There is no documented native webhook that triggers suspension when internal metrics fall below a threshold. No official minimum traffic recommendation for cost-latency balance is published.

Likely explanation, not verified: External monitoring services could in theory call Replit APIs to stop a Repl, but there is no verified, documented API for programmatically toggling Always On. Any automation would be unsupported and subject to change, with potential rate limits and state desynchronization.

Practical handling for low-traffic workloads

• Keep Always On enabled only when latency requirements demand it. Disable it manually during known idle periods via the Repl settings.
• Do not rely on traffic-based auto-suspend. Cold start latency will occur on the next request if the Repl is stopped.
• Ensure state is persisted externally if you consider manual off-hours shutdown, as in-memory data is lost on stop.

One missing detail that changes the recommendation: which Replit product you are using, Replit Deployments vs a standard container-based Repl, and your current plan tier. Deployment lifecycle controls differ from classic Repls and API availability is plan-dependent.