The Maintenance Window

What happens, in order#

At the configured hour (or on demand), the Platform coordinates a full stop: engines, message engines, integration engines, servers, data sources, notification servers, and consumers are all stopped — on every platform in the instance, the parent waiting for children to confirm. Then, with the system quiesced, it runs:

1. Backup — the built-in database backup
2. Update transition times
3. Purge — value retention, per interval
4. Reindex — fragmentation-driven index maintenance
5. Update statistics
6. Update freeze points

…then everything restarts. Each step's duration is recorded, which is what the maintenance activity you can observe is reporting.

Two operational consequences fall straight out of the design:

• Maintenance is a nightly outage by design. Collection pauses; late-night data arrives afterwards via refresh offsets. Schedule it accordingly (MaintenanceTime), and never during a shift handover that reads live dashboards.
• A failed step delays everything behind it. The classic morning-backlog pattern — "metrics behind every morning, caught up by noon" — is very often a reindex that runs long or fails, nightly.

The properties that govern it#

All are system properties (Flow Config → System):

Freeze points move here#

Step 6 is worth pausing on: maintenance advances freeze points. The freeze behaviour described in Interval Types and Time Schemes is not only a manual setting — the window maintains it. If old periods "stopped updating on their own", this is where it happened, by design.

When maintenance does not run#

The trigger condition is simple — last run before today, current hour past MaintenanceTime — but the coordination can fail: if not all platforms confirm shutdown, the run logs a warning and proceeds regardless; if the platform process was down across the window, the run happens when it next checks. Diagnosis order:

1. Did it start? The engines-stopping activity at MaintenanceTime is visible in the Monitor and logs. No stop → check the property's value and that the Platform (Bootstrap) was actually up at that hour.
2. Did a step hang? A step exceeding MaintenanceTimeout fails that step; the durations recorded per step identify which.
3. Visibility changed after upgrade? Sites report seeing less step-by-step detail in newer versions' logs — the steps still run; confirm by duration records rather than by narrative log lines.

To force a run for testing, set MaintenanceRequest rather than waiting for the hour.

Index rebuild failures#

The reindex step reads each index's fragmentation and applies the configured action per band. Failures cluster in three causes:

• Time: rebuilding large value-table indexes inside the window on a big instance simply takes longer than the timeout. Options: raise MaintenanceTimeout, set HighFragmentationAction to REORGANIZE (resumable, lighter, less thorough), or move heavy index work to a DBA-run job outside Infohub and let Infohub's step handle the remainder.
• Space: a REBUILD needs working space; a nearly-full data volume fails it nightly.
• Contention: something else scheduled in the same window (DBA jobs, backups at the SQL level). Coordinate — a site whose DBA policy owns maintenance should disable the overlapping Infohub steps (Backup off where the DBA backs up; keep whose-job-is-it explicit).

One site failing nightly while a smaller one succeeds is almost always the time cause — the difference is data volume, not configuration.

Division of labour with your DBA#

The window overlaps ordinary DBA work, and doubled maintenance is worse than either alone:

See Database Maintenance for the DBA-side practice.

See also#

• Database Maintenance
• Backup and Recovery
• Backfilling and Recalculation
• Monitoring Infohub and Its Health