Choosing Between Glitch Pro Always‑on and External Ping for Keeping Containers Awake

Timer Behavior During Container Sleep

JavaScript timers, including setInterval and setTimeout, do not execute while a Glitch container is in its automatic sleep state. Because the underlying Node.js process is suspended by the platform, the event loop is effectively paused. Timers do not "elapse" in the background; they are frozen until an external HTTP request wakes the container.

Likely Explanation vs. Confirmed Behavior

It is a confirmed platform behavior that free-tier containers sleep after five minutes of inactivity. The likely technical explanation is that the container is paused at the OS/cgroup level, meaning no CPU cycles are allocated to the process. Consequently, any background task relying on setInterval will stop entirely and will not "catch up" or trigger a burst of missed callbacks upon waking; it simply resumes from where it paused.

Choosing a Wake Strategy

Depending on your requirement for periodic execution, choose one of the following paths:

Option 1: Glitch Pro Always-on

• Use Case: High-precision timing, continuous background processing, or low-latency responses.
• Behavior: Prevents the process from suspending, ensuring the Node.js event loop runs uninterrupted.
• Trade-off: Constant RAM consumption against your project limits.

Option 2: External Ping Services

• Use Case: Occasional tasks where a few minutes of drift is acceptable.
• Behavior: An external service sends an HTTP request to wake the container. The timer resumes only after the request is received.
• Trade-off: This creates a "flapping" cycle (Wake → Execute → Sleep), leading to cold-start latency for users.

Verification Steps

To verify the sleep behavior in your specific project environment, use this scoped test:

1. Create a route that logs a timestamp to an external logging service or a persistent file every 60 seconds using setInterval.
2. Leave the project inactive for 15 minutes.
3. Check the logs. If there is a gap of 10+ minutes, the process was suspended.

Diagnostic Detail Needed: Does your background task require strict interval precision (e.g., every 60 seconds exactly), or is it acceptable for the task to run only once every time the container is woken by a user or ping?