Consumer Maintenance Policies for Native App Upgrades

1.What a maintenance policy controls

Automatic upgrades usually begin as soon as the provider sets a new release directive. A consumer-controlled maintenance policy changes this. It lets the consumer keep upgrades out of specific time periods: if a policy is set, the upgrade is delayed until the start date and time the policy defines. Without a policy, the upgrade begins when the default upgrade time is reached.

A policy schedule only says when upgrades may begin. You cannot set an end time or a duration. Each app or account can have only one maintenance policy. In practice, the schedule is a recurring start time, such as Saturdays at 02:00 UTC, when upgrades are allowed to begin.

A policy controls the timing of an upgrade, not whether it happens. Snowflake automatically upgrades Native Apps when a provider releases a new version or patch. During an upgrade the app's code is replaced, while data inside the APPLICATION boundary is preserved. The maintenance policy only changes when that automatic upgrade is allowed to start.

Sources1

2.Creating, applying, and changing a policy

A maintenance policy is a schema-level object. You create it with CREATE MAINTENANCE POLICY. Its SCHEDULE uses the same 'USING CRON <cron_spec> <timezone>' syntax as the SCHEDULE parameter of CREATE TASK. The policy name must be unique within its schema, and COMMENT is an optional description.

CREATE MAINTENANCE POLICY my_maintenance_policy
  SCHEDULE = 'USING CRON 0 2 * * SAT UTC'
  COMMENT = 'Weekly Saturday maintenance policy';

Creating a policy has no effect until you apply it. ALTER ACCOUNT applies it to every app in the account, and ALTER APPLICATION applies it to one app. The same two commands also remove a policy, so the scope of a policy is always set by which of the two commands you run.

ALTER ACCOUNT SET MAINTENANCE POLICY my_maintenance_policy FOR ALL APPLICATIONS;

ALTER APPLICATION my_app SET MAINTENANCE POLICY my_maintenance_policy;

To change the schedule later, use ALTER MAINTENANCE POLICY ... SET SCHEDULE. The same command can also SET or UNSET COMMENT, or RENAME TO a new name. SHOW MAINTENANCE POLICIES lists the policies for an account or app. DESCRIBE MAINTENANCE POLICY shows the details of one policy. DROP MAINTENANCE POLICY removes a policy from its schema.

ALTER MAINTENANCE POLICY my_maintenance_policy SET
  SCHEDULE = 'USING CRON 0 3 * * SUN UTC';

CREATE MAINTENANCE POLICY my_maintenance_policy
   ?  = 'USING CRON 0 2 * * SAT UTC'
  COMMENT = 'Weekly Saturday maintenance policy';

Sources21

3.Provider opt-in and the upgrade deadline

The provider decides whether a consumer's policy applies to a given release. In the release directive, the provider sets UPGRADE_IN_MAINTENANCE_WINDOW = TRUE. When that parameter is TRUE, UPGRADE_DEADLINE is required. The deadline is the latest time the upgrade can wait, and after it passes the upgrade runs whatever the consumer's policy says. Because of the deadline, a consumer cannot postpone an upgrade indefinitely. The two timing controls cannot be combined: a release directive cannot set both UPGRADE_AFTER and UPGRADE_IN_MAINTENANCE_WINDOW.

ALTER APPLICATION PACKAGE my_app_package
  MODIFY RELEASE CHANNEL DEFAULT
  SET DEFAULT RELEASE DIRECTIVE
  VERSION = v1_0
  PATCH = 2
  UPGRADE_IN_MAINTENANCE_WINDOW = TRUE
  UPGRADE_DEADLINE = '2026-2-10T10:00:00Z';

For consumers, the practical advice is to schedule upgrades soon after a release arrives, at a time when someone is available to test and adjust. If the upgrade is left to run at the deadline, the app may become unavailable at a moment you did not plan for.

For apps that use Snowpark Container Services, the provider can also set AUTOMATIC_APPLICATION_MAINTENANCE = TRUE on the application package. Without it, application upgrades and compute pool node maintenance are separate concerns that can happen at different times. With it, both are coordinated into the consumer's chosen window, and the application upgrades first.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Once a consumer applies a maintenance policy, every upgrade from every provider automatically waits for that window.Why is that wrong?

   A policy only applies when the provider releases with UPGRADE_IN_MAINTENANCE_WINDOW = TRUE. The provider has to opt in explicitly.

   Covered in Provider opt-in and the upgrade deadline

2. 2.A sparse maintenance schedule lets a consumer delay an upgrade for as long as they want.Why is that wrong?

   The provider's UPGRADE_DEADLINE caps the delay. After the deadline, the upgrade proceeds no matter what the consumer's policy says.

   Covered in Provider opt-in and the upgrade deadline