Load average is the kernel's own estimate of system demand, published as three exponentially damped numbers covering roughly the last 1, 5, and 15 minutes. It counts tasks, not percentages, so it has no upper bound: a value of 40 is perfectly possible and simply means 40 tasks were waiting on average.
The detail that trips people up is what Linux puts in the count. Unlike most other Unix systems, Linux includes tasks in uninterruptible sleep (state D), which usually means blocked on disk or network filesystem I/O, in addition to tasks that are runnable. That is why a Linux box with mostly idle CPUs can still report a load of 40 when an NFS mount hangs, and why the identical workload shows a lower load on BSD. The second rule is to read the number against the logical core count. A load of 8 on an 8 core host is fully committed; a load of 8 on a 2 core host means work is queuing four deep.
Because it blends CPU demand and I/O stalls into a single number, load average makes a good first look and a poor standalone alert. The practical approach is to trigger on load per core sustained over several minutes, then read CPU time per state and disk I/O to find out which half is responsible. Hyperping collects the 1, 5, and 15 minute load averages alongside the logical core count, so the per core ratio is there without doing the arithmetic by hand.