A data lab consumes resources: it runs on a server, it stores data on disks (volumes), and it keeps backups. The Usage and KPIs page of a lab gives you a single place to see how much a lab has been used, what it costs, and when it was actually running. Use it to monitor consumption, understand a bill, and decide how to reduce a lab's footprint.
Choosing what to measure
Every figure on the page is computed over a period and can be narrowed to specific users. Changing either recalculates the whole page.
- Period — pick a preset (current month, current year, last 7 days, last 30 days, last 365 days, or all time) or choose Custom to enter your own From and To dates.
- Users — filter the usage to one or more members of the lab, to see who drove the consumption over that period.
Usage costs
For a cloud lab that is billed by usage, the page summarises the cost of the selected period across the different things a lab consumes:
- Server — the compute cost, shown with the total number of hours the server was running. Only labs billed by the hour show a server cost.
- Volume storage — the cost of the disks attached to the lab, with the duration they were provisioned. An info button opens a detailed breakdown per volume.
- Backup storage — the cost of keeping the lab's backups.
- Backup transfer — the cost of the data moved when backups are taken.
- Total — the sum of server plus all storage costs for the selected period.
Running periods
Below the cost summary, the Running periods table lists each interval during which the lab server was actually up over the selected period. It is the detailed record behind the total running time, useful to see when and by whom the lab was used.
Volume history
A volume is a disk attached to the lab. Because storage is billed for as long as a disk exists, the lab keeps a history of the volumes it has had, so past storage costs can be understood. Each entry records:
- Volume size — the disk size in GB, and its type: Classic or High speed.
- Start date and End date — the period the volume was in place (an open end date means it is still active).
Green computing options
Because a running server has both an environmental and a financial cost, a lab can carry green computing options: rules that automatically stop the server when it is no longer needed. This is the most direct way to cut a lab's server usage. As a safeguard, a lab is never stopped while a scenario is running or waiting in the queue.
- Stop after scenario — stop the lab once there is no running scenario and none queued.
- Stop after backup — stop the lab once no backup is in progress.
- Stop after a specific time — stop the lab at a set time of day (hour and minute, in a chosen timezone).
- Stop after inactivity — stop the lab after a set number of minutes without activity.
Each option can be persistent (it stays active and applies every time the condition is met) or not persistent (it runs once and is then removed).
