Last pulled time is a useful hint, not a safe deletion signal on its own. An image that runs quietly for months may not be pulled at all until a node restarts. Amazon ECR reflects this caution: its pulled time rule can only archive images, and expiry comes later.
What the signal captures
If an image has not been pulled in months, nothing new has started from it. That is a good sign that it is unused. If an image was pulled yesterday, something is using it. The signal is strongest in the second case and weakest in the first.
Where it misleads
A pull happens when a node needs the image and does not have it cached. A stable workload on a long running node pulls once, then runs for months. A scheduled job on warm nodes may never pull. When the node is replaced during an upgrade or failure, the pull happens, possibly from a very old image, at the worst moment.
So "not pulled in 90 days" can mean unused, or it can mean running on cached nodes. Cross check with what is deployed.
How ECR designs around it
The ECR documentation describes a pulled time count type with several specific rules:
- It is used with a transition action to archive storage, and it cannot be used with the expire action.
- To delete based on pull activity, first archive with the pulled time rule, then expire with a rule on time since transition.
- Images must be in archive storage for a minimum of 90 days before deletion.
- If an image was never pulled, its pushed time is used instead.
- If an image was archived and restored but not pulled since, its last activated time is used.
That two stage design gives you a window to notice a problem and restore, instead of deleting on a hint alone. It is a good pattern to copy even where your registry lacks it: mark, wait, then delete.
A safer process for any registry
- Use last pulled time to list candidates.
- Subtract anything in your deployment config or cluster.
- Mark the remainder as deprecated, with a tag or label, and tell owners.
- Wait a defined period.
- Delete, after a final check.
Pull counts are not an owner
Even a pulled image might belong to nobody. Pull activity tells you something is using it, not that anyone is patching it. Pair pull data with ownership and with an age limit, see how old is too old for a container image.
Record why an image was removed
When a cleanup removes an image, keep a line saying which signal selected it and who reviewed the list. If a service later fails to start, you can tell quickly whether the cause was a cleanup, and you can improve the rule. Over a few cycles this record also shows whether your pull time threshold is too tight for your slowest services.
Quick check
Can I delete images with no pulls in 90 days?
Not safely on that alone. Compare with deployed images, and prefer an archive or deprecate stage first.
What does ECR do for never pulled images?
It uses the pushed time in place of the last pulled time, per its documentation.
Sources
Last reviewed: 19 October 2026.
