Yes, it only happens in DEV. Usually on the first log in or access for the day. After that, it should works fine.

You can refer to this forum post, thank you.

Hi Nicolas,

Good question. This is a known pain point in ODC, and it comes up more often now that agentic apps are becoming a real pattern.

What you're describing is consistent with cold-start behavior. Since ODC runs each app as its own container, the platform may scale down idle containers to free up resources. When a request comes in after a period of inactivity, the container needs to spin back up, which could explain the 10+ second delay you're seeing.

I can't confirm whether this behavior is limited to Development or applies across all stages, but it tends to be far more noticeable in Dev simply because traffic is sporadic there. Production workloads with regular traffic would naturally keep containers warm.

Here are a few things worth trying:

1. WakeUp component from Forge (https://www.outsystems.com/forge/component-overview/20575/wakeup-odc). This was built specifically to solve the sleeping app problem in ODC. It publishes periodic events (every 15 minutes, hourly, or daily) that your app subscribes to with a handler action. The reason it may work better than a regular Timer is that it uses events rather than scheduled jobs, so the handler is expected to run in your app's own context, which should keep the container warm. I haven't verified the internal mechanism myself, so I'd treat it as a strong candidate to test: subscribe to the Ping_15 event in your agentic app, define a lightweight handler (a simple log entry), and after 15+ minutes of inactivity call the app's service action to see if the cold start is gone.

2. Open a support case with OutSystems. Ask specifically about the idle timeout per stage and whether there's a way to prevent containers from scaling down for a given app. This is especially relevant for agentic workloads where latency on the first call directly impacts the experience. Even if there's no toggle today, having the case on record helps prioritize it as a feature request.

3. Design for graceful warm-up. Regardless of which keep-alive strategy you use, avoid heavy initialization logic that blocks the first incoming request. If your agentic app needs to load configuration, establish external connections, or warm caches, consider doing that lazily on first use with sensible defaults, so the caller isn't stuck waiting for everything to initialize at once.

A note on Timers: a plain Timer might seem like the obvious first choice, but in ODC Timers run in separate job containers rather than in the container that serves HTTP requests. A Timer firing every 5 minutes would keep the job container alive but likely would not prevent the HTTP container from scaling down. That's why the event-based approach from WakeUp is worth trying first.

The quick win is to set up WakeUp and measure whether your 10+ second startup drops. That will also confirm whether event-driven keep-alive actually prevents the container from going idle in your stage.

Hope this helps, let me know how it goes.

Hello @Nicolas Körner 

In addition to what was already mentioned, you can also refer to the following link.

https://success.outsystems.com/documentation/outsystems_developer_cloud/managing_outsystems_platform_and_apps/monitor_odc_resource_capacity/