Storage Expiration in Appwrite 1.0.0: Uncertain Inclusive Behavior

Storage Expiration in Appwrite 1.0.0

Appwrite 1.0.0 introduced a new expiresAt field for storage files, allowing automatic deletion after a specified UTC timestamp. This feature is intended to free storage space without manual cleanup.

The cleanup mechanism runs hourly on the server, which can delay deletion by up to 60 minutes. Documentation does not state whether the timestamp is inclusive or exclusive, creating uncertainty about the exact moment a file is removed.

Additionally, there is no API to query the remaining time before expiration, and misconfigured or disabled cleanup jobs in custom deployments can cause expired files to persist. Clients that use local time instead of UTC may also set incorrect expirations.

Given these gaps, developers need to understand the exact semantics of expiresAt and how to verify cleanup timing in their environments.

• Does the cleanup job delete a file exactly at the expiresAt timestamp, or only after the next hourly run?
• Is the expiresAt value interpreted inclusively (file still present at the timestamp) or exclusively (file removed at the timestamp)?
• What mechanisms exist to programmatically determine the remaining time before a file expires, or to force immediate cleanup?