# Backup Runtime **Purpose:** How long jobs take, and how much that varies. A range chart plotting each job's shortest, latest, and longest runtime on one row, with a matching grid. It is the backup window screen. ![Backup Runtime range chart plotting shortest, latest and longest runtime in minutes per backup job, with job names redacted](https://visualoneintelligence.com/wp-content/uploads/2026/08/voi-docs-backup-runtime-chart.png) ## When to use it - Find jobs that no longer fit the backup window - Identify jobs whose runtime is wildly inconsistent - Plan schedule changes with real duration data rather than estimates - Check whether a job's latest run was normal for it or an outlier ## Key areas and metrics The chart plots one row per job, with runtime in minutes along the x-axis. Each row carries several markers connected by a line, showing the job's shortest, latest, and longest observed runtime. Jobs are ordered by longest runtime, so the slowest sit at the top. ![Backup Runtime grid listing shortest, longest and latest runtime per job, with job names redacted](https://visualoneintelligence.com/wp-content/uploads/2026/08/voi-docs-backup-runtime-grid.png) The grid carries the same four fields: Job Name, Shortest Runtime, Longest Runtime, and Latest Runtime, all in minutes, and can be sorted and grouped like any other grid in the product. ## The spread is the finding, not the maximum A long bar on this chart means the job's runtime is unpredictable, and unpredictability is harder to schedule around than a consistently slow job. A job that always takes ninety minutes can be planned for. A job that takes anywhere between two minutes and thirty-six hours cannot. - **Wide spread with a short latest.** Usually incremental behaviour: quick most nights, very long when a full runs or a large change lands. Plan the window for the long case. - **Wide spread with a long latest.** The job is currently in its slow state. Worth checking whether it finished inside the window last night. - **Narrow spread at a high value.** Consistently slow, which is at least predictable and is the easiest kind to schedule. - **Shortest at or near zero.** Runs that ended almost immediately, which often means the job found nothing to do rather than that it was fast. ## Common actions - **Compare longest runtime against your window length.** Anything longer has already overrun at least once, whether or not anybody noticed. - **Sort the grid by longest runtime descending** and work down. - **Read latest against shortest and longest** to judge whether the current state is normal for that job. - **Look for zero shortest runtimes** and check the job in Backup Status, since a job protecting nothing will complete instantly and report success. ## Tips > Runtime is in minutes, so a value in the thousands is a job running for many hours. Convert before quoting it in a change discussion, because four figures on a chart understate how alarming a thirty-six-hour backup is. > Job names are the most revealing labels in the section, and on this screen they form the entire chart axis. They commonly encode site, application, and compliance scope. Redact the axis before sharing. ## Related screens [Backup Status](https://visualoneintelligence.com/docs/backup-status/) shows whether these jobs succeed as well as how long they take. [Backup Host Occupancy](https://visualoneintelligence.com/docs/backup-host-occupancy/) shows the data volume behind a slow job. [Backup Pool Summary](https://visualoneintelligence.com/docs/backup-pool-summary/) covers whether the target has room. --- Source: https://visualoneintelligence.com/docs/backup-runtime/