Backup and Deploy Automation
How backup and deploy-adjacent operations are automated — the jobs that protect site state.
Backup and Deploy Automation in SGEN is the category of platform-managed automation that protects site state across change windows. Scheduled backups, deploy-adjacent snapshots, post-deploy health checks — every job whose purpose is to keep the site recoverable falls inside this category. This page is the Reference definition of the category.
What is this for?
Read this page when you want the structural definition of SGEN's backup-and-deploy automation category — what jobs run, what triggers them, and how they pair with the broader recovery posture.
Good use cases
- You are scoping operator confidence around change windows and need the automation model.
- You are explaining to a stakeholder how SGEN protects site state during deploys.
- You hit a "did the pre-deploy backup run?" question and want the model laid out.
- You are designing internal SOPs around deploy windows.
What NOT to use this for
- Step-by-step backup configuration procedures — open the relevant Guide.
- Per-release shipped automation additions — open What's New or Changelog.
- The backup primitive itself — open Backups (Migration sub-page).
- Recovery framing — open Recovery Considerations.
How this connects to other features
- Automation Overview — parent Reference area.
- Trigger Model — defines the event-driven part of the automation.
- Scheduled Processes — defines the schedule-driven part of the automation.
- Backups — the foundational safeguard the automation drives.
- Recovery Considerations — the broader recovery framing this automation feeds.
Definition
Backup and Deploy Automation in SGEN is the category of automation jobs whose purpose is to keep site state recoverable. The category covers scheduled backups (the platform's baseline safeguard), pre-deploy snapshots (event-driven safeguards), post-deploy health checks (validation that the change landed cleanly), and the surrounding notification logic.
The defining property is protective. Every job in this category exists to make the site easier to recover from — either by capturing a known-good state ahead of time, or by validating a state change after the fact.
Purpose
The purpose of this page is to define the backup-and-deploy automation category as a Reference layer. It explains the shape of the jobs in scope, how they pair with the Migration Backups Reference, and where their outcomes surface.
Scope
This page covers the backup-and-deploy automation category at the Reference level.
The page covers:
- The kinds of jobs in the category.
- The trigger and schedule sources for each.
- Where outcomes surface.
- The boundary against the Backup primitive itself (Migration Backups).
- Per-step backup configuration — Guides.
- The Backup primitive — Backups Reference.
- Recovery framing — Recovery Considerations Reference.
Jobs in scope
Four categories of automation belong here.
Scheduled backups
The platform's baseline safeguard. Daily snapshots at the per-site cadence (plan-aware) provide the recovery target operators rely on by default. The Scheduled Processes Reference covers the cadence model; this page covers the backup-job specifics.
On-demand pre-deploy snapshots
Triggered manually before a planned high-stakes operation (theme change, migration, custom-code deploy). The on-demand snapshot becomes the rollback target if the operation does not behave as expected.
Post-deploy health checks
Triggered automatically after a deploy event. Confirms the deploy landed cleanly by walking a defined health path (key pages render, key endpoints respond). A failing health check fires a high-priority notification.
Backup-and-deploy notifications
Notification Logic delivers the operator-facing seam — backup completed, snapshot retained, post-deploy health pass or fail.
Site · Automation · Backup & deploy
Recent activity
Post-deploy health check passed
14 pages walked, 0 failures · automated check
Pre-deploy on-demand snapshot
Captured before theme update · 248 MB · retained 30d
Daily backup completed
Scheduled · 247 MB · verified
Pre-deploy health check warning
1 page returned slow response · within tolerance
Where outcomes surface
Backup-and-deploy automation outcomes surface in the standard places.
Backup history
Inside the admin Backups module and the SG-Dashboard Site Manager backup index. New snapshots appear as they complete.
Notification surface
Per the operator's notification preferences (per Notification Logic). Backup-completion notifications surface there; post-deploy health-check failures surface as high-priority notifications.
Deploy history
Where the deploy itself is recorded (per-site change history), the linked pre-deploy snapshot and post-deploy health-check result surface alongside the deploy entry.
Constraints and boundaries
Backup and Deploy Automation is a Reference area for the protective automation category. It is not a substitute for the Backups Reference (the safeguard primitive) or for Recovery Considerations (the broader recovery framing).
Use this Reference for:
- Understanding the protective automation jobs in scope.
- Confirming what fires each job.
- Reasoning about deploy windows and the safeguards around them.
- The Backup primitive itself — Backups Reference.
- Recovery framing — Recovery Considerations.
- Step-by-step configuration — Guides.
Public boundary
This page is intentionally public-safe. It does not expose backup-engine internals, exact health-check paths, or protected operational identifiers.
Examples
Example 1 — Daily backup runs and Notification Logic delivers confirmation
The daily backup runs at the per-site cadence. Notification Logic delivers a "backup complete" notification per the operator's preference. The snapshot appears in the admin Backups module.
Example 2 — Operator triggers pre-deploy snapshot
The operator triggers an on-demand snapshot before a theme update. The deploy proceeds, the post-deploy health check passes, and Notification Logic delivers a "deploy clean" confirmation. If the post-deploy check had failed, the snapshot would have provided the rollback target.
Example 3 — Post-deploy health check surfaces a regression
A deploy lands and the post-deploy health check detects that one page is returning a server error. The check fires a high-priority notification. The operator opens the deploy history surface, sees the pre-deploy snapshot, and decides between fix-in-place and rollback per Recovery Considerations framing.
Documentation guidance
Use this page as the structural definition for the backup-and-deploy automation category. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog. Cross-reference Backups for the safeguard primitive and Recovery Considerations for the broader recovery framing.Reading order
Open this page when scoping deploy windows or operator confidence around change. Pair with Backups for the underlying safeguard and Recovery Considerations for the rollback framing. Pair with Scheduled Processes for the cadence model behind the daily backup job.
Related reading
- Automation Overview — parent Reference area.
- Trigger Model — event-driven layer.
- Scheduled Processes — time-based layer.
- Backups — the safeguard primitive.
- Recovery Considerations — broader recovery framing.
Vocabulary cross-reference
- Scheduled backup is the daily-cadence baseline safeguard.
- On-demand snapshot is an operator-triggered backup before a planned operation.
- Post-deploy health check is the automated validation that runs after a deploy.
- Deploy window is the time period covering pre-deploy capture, deploy execution, and post-deploy validation.
- Protective is the property that defines what belongs in this category — every job exists to make recovery easier.
Maintenance discipline
When backup-and-deploy automation changes across releases (new health-check path, new snapshot trigger, new notification rule), update this Reference and log the change in Changelog. The page stays valuable because the protective framing stays small.