Downtime during deployments

2025/05/13 5:10 PM

Are there any criteria for when a SaaS deployment requires taking down the site? We've noticed that some of our deployments don't seem to incur downtime, but others take our site down for 20-30 minutes. Without any guidelines on when we'll see downtime, we're forced to schedule all of our deployments for the overnight hours.

I know that some of the delay is due to backups and other data safety tasks. We're big fans of safety! But we're also big fans of getting a good night's sleep. If we can have some guidelines on when we can expect downtime, that would be great.

Environment

Tags:
SaaS Deployments

Answers

2025/05/13 6:44 PM
Accepted answer

There are several two primary scenarios you can encounter during deployments

  1. Code-only deployment - your deployment is "code changes only" and does not need a database backup or db changes. Therefore we can process the package, deploy the code to the offline App Service slot, do some house keeping and file system backups, and then swap the slots. You'll typically see the Xperience application updated before it shows the deployment as finished in the Xperience Portal because we also have some post-deployment house keeping.
    The deployment might take a few minutes to complete but you shouldn't experience any downtime.
  2. Database change deployment - your deployment has CD repository changes (the hash of the last deployment's CD repository does not match the current's), you are updating the version of Xperience currently deployed to the environment, or you are deploying $StorageAssets (only relevant for the media library, which we recommend not using at this point), then we probably need to make database changes and we conservatively assume we do.
    This scenario requires downtime after we do some preparation for the deployment but before we swap slots. We have to backup the database and ensure we don't lose data while performing the backup, so we take the app offline.

Scenario 1 won't experience downtime and scenario 2 will.

We have several upcoming SaaS deployment updates on the Xperience roadmap to improve both scenarios.

  1. Deploy straight to production - helps scenarios 1 & 2
  2. Optimized database backups - helps scenario 2
  3. Zero-downtime deployments and related improvements - helps scenarios 1 & 2
2025/05/13 6:47 PM

Kentico’s SaaS infrastructure is designed to minimize downtime as much as possible, but downtime can occur under certain conditions, mainly for safety and data integrity reasons.

When Downtime Might Occur

  1. Schema Changes
    • Adding or removing fields, content types, or altering structure in ways that affect the database schema.
    • These typically trigger a brief maintenance window and may result in temporary downtime (10–30 minutes).
  2. Database-Level Changes
    • Complex operations such as data migrations or structural changes to stored content.
    • Triggers backups, consistency checks, and may require exclusive locks on resources, leading to longer downtime.
  3. Project Upgrades or New Version Rollouts
    • If a deployment includes upgrading the core Xperience libraries or services, downtime may occur while the system restarts and migrates internal state.
  4. Manual SaaS Environment Reprovisioning
    • When environments are manually reprovisioned or reset, either by support or advanced DevOps triggers.

When Downtime Is Unlikely (Safe for Daytime Deployments)

  • Pure frontend changes (e.g., Razor/React/HTML/CSS updates).
  • Adding or updating widgets, page templates, or views.
  • Updating localization strings or styling.
  • Adjustments in webhooks or content staging settings.
  • Deployment of content changes only (via API or Xperience Admin).

Best Practices to Minimize or Avoid Downtime

  1. Bundle Structural Changes Together
    • Avoid many small schema changes across multiple deployments. Group them if possible.
  2. Use Previews/Staging to Test
    • Verify schema changes on staging environments before applying to production.
  3. Coordinate with Kentico Support
    • For large changes, you can request scheduled downtime or get insight into the estimated duration.
  4. Deploy with Smart Windows
    • If you don’t know whether your deployment causes downtime, aim for late evenings or early mornings until confident.

To response this discussion, you have to login first.