Start order is a delay, not a dependency

The host comes back after a power cut and half of what should be running is not. The database machine is up but the application in front of it gave up, or a container failed to mount storage that another container was still bringing online. Nothing is broken and nothing logged an error worth reading. The pieces simply came up in the wrong order.

This is the one place where the shape of your setup, which guest depends on which, stops being a diagram in your head and becomes something the machine actually executes. It is worth knowing precisely what that mechanism does, because it is narrower than most people assume.

The sentence that explains most surprises

Startup delay is an interval, not a condition.

When you set a delay on a guest, Proxmox VE starts that guest, waits the number of seconds you gave it, and then moves on to the next one. It does not check whether anything inside the guest finished booting. It does not check whether a service answers. It waits, then continues.

So the arrangement in your head, "the app waits for the database", is never what gets configured. What gets configured is "the app starts ninety seconds after the database was told to start". On a quiet test reboot those two are indistinguishable. After a real power cut, when disks are slower, a filesystem check runs, or a guest boots into recovery, they are not.

Four rules worth knowing before you set numbers

Lower starts first, and shuts down last. The shutdown order is the reverse of the start order; there is no separate setting. A guest with order 1 is the first up and the last down, which is usually what you want for the thing everything else depends on.

Equal numbers are not random. Guests sharing the same order are additionally sorted by ID, ascending. That means ties are stable and predictable, and it means you do not need to give every guest a unique number to get repeatable behaviour.

Guests with no order always start after guests with one. This is more useful than it sounds. You do not have to number everything. Number the three or four things that genuinely have to be early, and leave the rest alone.

The order applies to one host, not to the cluster. It cannot express "this guest on node A must come up before that guest on node B". The moment your dependency crosses a node boundary, this mechanism has nothing to say about it.

The trap that appears later

Guests managed by the high availability stack ignore both the start on boot setting and the boot order. The startup and shutdown routine skips them entirely, because the HA manager decides when they run.

This one bites late. A single host with a carefully tuned order works for a year. Then a second node arrives, a few guests move under HA, and their ordering quietly stops applying. Nothing warns you, because nothing is wrong; the responsibility simply moved.

The delay you actually want is often a different one

A common reason people reach for guest delays is an external resource: network storage that has to be reachable before anything mounts it, or a switch that needs a moment. Spacing out individual guests is an awkward way to buy that time, because it stretches the whole sequence.

There is a separate per-node setting for exactly this: a delay between the host finishing its own boot and the first auto-starting guest. One number, applied once, at the point where the waiting actually belongs.

The number nobody sets until it hurts

Shutdown timeout defaults to 180 seconds per guest. Proxmox VE asks the guest to shut down, waits, and if the guest is still running when the timeout expires it is stopped forcefully. A bulk stop of every guest has its own overall limit of three minutes before the same thing happens.

For a machine that flushes to disk on shutdown, that ceiling is worth checking on purpose rather than discovering during an outage. The default is generous for most guests and too short for a few, and the few are exactly the ones where a forced stop costs you something.

What we actually see in practice

On the host used to check the behaviour described here, nine guests were configured and three were set to start on boot. Not one had a start order.

That is the normal state of things, and often it is fine. Machines that do not depend on each other do not need an order. The point of writing it down is narrower: if you have ever said out loud that one guest needs another to be up first, then that sentence currently lives only in your memory, and a power cut does not read your memory.

What Atlas does

Atlas does not reorder anything for you and does not invent a dependency system on top of the one Proxmox VE has. What it does is make the relationships visible in one picture instead of one guest at a time, so the question "what actually depends on what here" can be asked while the machine is calm rather than while it is coming back up.

Seeing the shape does not configure it. But nobody sets a sensible order for a layout they have never seen drawn.