In general, startup complete is not reached as long as NetworkManager is busy activating a device and as long as there are profiles in activating state. During boot, NetworkManager starts autoactivating suitable profiles that are configured to autoconnect. If activation fails, NetworkManager might retry right away (depending on connection.autoconnect-retries setting). While trying and retrying, NetworkManager is busy until all profiles and devices either reached an activated or disconnected state and no further events are expected.

Basically, as long as there are devices and connections in activating state visible with nmcli device and nmcli connection, startup is still pending.

When a device reaches activated state, depends on its configuration. For example, with a profile with both IPv4 and IPv6 addressing enabled, the device is possibly considered fully activated when either of the address families is ready. This can be controlled with the ipv4.may-fail and ipv6.may-fail settings, to indicate that the address family is required. There are also ipv4.required-timeout and ipv6.required-timeout settings which affect how long to wait for an address family. Likewise, properties like ipv4.dhcp-timeout and ipv6.ra-timeout affect how long NetworkManager will try the IP configuration before giving up.

For example, a bridge or bond profile cannot do IP configuration without ports. When booting with such profiles that autoactivate without ports, NetworkManager-wait-online.service blocks until timeout. This is a configuration error.

Dispatcher scripts for the "pre-up" event run at a late stage during activation of a profile. These scripts block the activation for when NetworkManager considers the profile fully activated. See also NetworkManager-dispatcher(8) for details.

The connection property connection.wait-activation-delay also adds an additional delay during activation and delays startup complete. This is to workaround certain cases where a device is known to not be ready for a certain amount of time.

The property connection.wait-device-timeout of the connection profiles waits until the waited devices appear. This is useful if the driver takes a longer time to detect the networking interfaces. Similar with the connection.gateway-ping-timeout property.

With Wi-Fi devices, NetworkManager needs to wait for the first scan result to know which networks might be available. That always adds a delay.

With ethernet devices, NetworkManager waits for carrier until the configurable [device*].carrier-wait-timeout is reached. This is because some devices take a long time to detect carrier and it means to boot with cable unplugged, will unnecessarily delay NetworkManager-wait-online.service.