"Application Marked as Stale" — What That Notification Means

If you get a notification titled "Application marked as stale" or "Action required: inactive application", it means an app you left stopped has entered an inactivity cleanup process — and the fix is one click: start the app, and the state clears completely. The process is staged rather than sudden. An app becomes stale, then receives a few weekly warnings that tell you roughly how many days remain, and only then is it removed. Every stage produces a notification and an entry in the app's event history, so nothing happens without a trail you can read.

Does this apply to me?#

Probably not automatically, and it's worth being straightforward about that rather than alarming you.

The platform has the machinery for inactivity cleanup, but automatically marking stopped apps as stale is off by default in the codebase. That means an app sitting stopped isn't necessarily on a countdown — the staged warn-and-remove process advances apps that are already in the stale state rather than sweeping up every stopped app on a timer.

So the practical rule is: the notifications are the signal. If you haven't received one, you aren't in the process. If you have, the timeline below is what you're looking at.

Policy settings like this are configuration, so they can differ between deployments and change over time. That's another reason to treat the notification as the source of truth rather than a schedule you memorise.

The stages, if it does apply#

The defaults in the code are a staleness threshold measured in weeks, warnings roughly a week apart, and a small number of them before removal — so the whole sequence spans over a month, with several notifications. The warning message tells you the days remaining, which is more reliable than any figure I could quote here.

Starting the app clears it#

Whatever stage you're at before removal, starting the app resets the state entirely — the stale marker and the warning count both go.

You don't have to leave it running afterwards. The point is that the app stopped being inactive; you can stop it again once it's come up. If you're deliberately parking something long-term, that's the whole maintenance routine.

Where to look#

• Notifications feed in the panel. These are among the few messages the platform sends unprompted, so it's worth checking occasionally.
• The app's event history, which records gc_marked_stale, gc_warned, and gc_soft_deleted. If you're piecing together what happened to an app after the fact, that's the durable record — it survives when logs don't.

Removal isn't immediate erasure#

There's a soft-delete stage before anything is purged, with a retention window measured in days, and recovery from it is itself a recorded event. So an app that's just been removed isn't necessarily gone.

That's a grace period, not a guarantee, and it isn't something to plan around. The reliable version of "I want to keep this" is the same as on any host:

• Code in a repository, not only in the platform's build.
• Data in a backup you've actually downloaded, since nothing is backed up for you.
• Configuration written down — env var names, port bindings, volume paths.

Do those and a removed app is an inconvenience rather than a loss.

What this means for parking apps#

Stopping unused apps is still good practice — it frees CPU and RAM allocation for other apps and is the right way to pause a staging bot. Just pair it with awareness:

• Days or weeks? Stop it without thinking about this.
• Months? Start it occasionally, or make sure its code and data live elsewhere. Check your notifications either way.
• Trying to free disk? Stopping doesn't help — volumes belong to the app, not the container, so a stopped app still occupies storage. Delete files or the app itself.

That last one surprises people, because stopping is the instinct when disk is the problem and it doesn't move the number at all.

FAQ#

What does "Application marked as stale" mean?#

An app you left stopped has entered an inactivity cleanup process. Starting the app clears the state completely.

Will my stopped app definitely be deleted?#

Not necessarily — automatic marking is off by default, so a stopped app isn't automatically on a countdown. Treat the notifications as the signal: no notification, no process.

How do I stop the warnings?#

Start the app once. That resets the stale state and the warning count; you can stop it again afterwards.

How long do I have after a warning?#

The warning message includes the approximate number of days remaining. Use that rather than a fixed figure, since the policy is configurable.

Can I get a removed app back?#

There's a soft-delete window before permanent removal during which recovery is possible. Don't rely on it — keep code in a repository and data backed up.

Does a stopped app still use my quota?#

It doesn't consume CPU or RAM, but its volumes still occupy disk. Stopping frees compute, not storage.

Wrapping up#

Inactivity cleanup is a reasonable thing for a platform to do, and this implementation is about as considerate as it gets — staged, with warnings that count down, and a one-click reset. The main thing worth internalising is where the signal lives: your notifications and the app's event history, not a timer you have to track. And the advice that makes it a non-issue is the advice that's already worth following — keep your code in a repository and a copy of your data somewhere you control.