Provisioning: From Paid Order to Live Service

What this article covers

Between a paid document and a working service there is a delivery. For some products that delivery is a machine being built from bare metal over twenty minutes; for others it is a virtual machine created in ninety seconds, a container started on a game node, a rack unit reserved, or a line in your own notebook. This article follows that path end to end: what starts a delivery, the states it passes through, where you watch it, what the platform retries on its own, every control you have when it goes wrong, and what your customer sees at each point.

It is the companion to Services (the list) and Service Details (the per-service controls). Those articles describe the screens; this one describes what is happening behind them.

What actually triggers a delivery

Exactly three things start a delivery, and none of them is a status field.

1. The order’s billing document is paid. The moment an invoice or proforma covering a new order is settled — by card, by a gateway callback, by a payment you record by hand, or from the customer’s credit balance at checkout — every service on that order leaves Pending Payment and delivery begins.
2. The order is created billing-exempt. An order you raise with no charge produces no document to pay, so delivery starts as soon as the order is created. See New Order.
3. You start it yourself from the service, with Retry deployment, Retry Provisioning or Recreate.

Warning: Mark as Completed on an order does not build anything. It sets the order’s own status and sends your order-completed email, and that is all — no server is allocated, no machine is created, no plugin is called. If the order’s document is still unpaid, marking the order complete leaves the customer with a completed order and no service. The same is true of setting an order’s Payment field to Completed by hand: it corrects your books, it does not take money and it does not deliver. See Order Details.

Note: delivery only runs while Auto Provisioning is switched on, under Settings → Billing → Automation (described as “Provision services when paid”). It is on by default. With it off, paid orders create services that sit at Pending until you deliver them by hand. See Billing Settings.

The states a delivery passes through

Service states during and after a delivery

State	What it means
Pending Payment	The service record exists but the order’s document has not been settled. Nothing is being built. This is the normal state of a service between checkout and payment.
Pending	Paid (or exempt) and queued. For most products this state lasts seconds. For a product nothing provisions automatically it is the resting state until you activate the service yourself.
Installing	A hardware deploy has been dispatched and the operating system is being written. Normal and temporary. Only bare-metal deliveries use this state.
Active	Delivered. The delivery date is stamped, the parent order closes itself out, and renewal billing begins from here.
Provisioning Failed	A step of the delivery failed. The reason is recorded on the service and the recovery controls become available.

A service that reaches Active also closes its order: once every service on an order is delivered, the order flips from Pending to Completed on its own and your order-completed email goes out. An order with several products only completes when the last one lands, so a part-delivered order stays Pending — which is the signal that one line is still stuck.

Note: the failure state is reached deliberately rather than by timeout. When a delivery cannot proceed — no matching hardware, no address to give the machine, an unreachable provider — the platform records the reason and stops, rather than half-building something. A service that reaches Provisioning Failed has had every resource it grabbed released again wherever that was possible.

Delivery by product type

What happens between Pending and Active depends on how the product is configured to be delivered. This is set on the product itself — see Products.

Manual products

Nothing is automated. The service is created, paid and left at Pending, and a task appears in the Automations panel reading that manual provisioning is required because no automation is configured. You do the work, then open the service, click Edit, set Status to Active and save. Use Resend Welcome afterwards to send the customer their details.

Dedicated servers from your own inventory

This is the longest path and the one with the most that can go wrong.

1. Allocation. A free machine matching the order’s specification, in the ordered location, is picked out of Inventory and bound to the service. See Allocation & Equivalences for how matching works.
2. Address check and allocation. Before a machine is taken, the platform checks that the addresses the order needs can actually be issued in that location. If they cannot, nothing is allocated at all and the service fails immediately with the reason. If they can, the machine is taken and the addresses are assigned from IPAM.
3. Hardware preparation. The switch port is enabled, the boot configuration is overridden, and the machine is powered on through its management interface.
4. Pre-flight. A set of checks runs before the install is dispatched: that an operating-system image is selected and downloaded, that the machine has a provisioning network address and a management address recorded in inventory, that the bare-metal provisioning service is configured and running, and that a provisioning agent for that location is online and current.
5. Install. The service moves to Installing and the operating system is written. When the machine reports back, the service becomes Active and its hostname and address are filled in.

Note: a bare-metal delivery does not send the welcome letter by itself. When the install completes, use Resend Welcome on the service to send the customer their address and root password. This is deliberate — most operators want to look at a new machine before handing it over.

Virtual servers on your own virtualisation

The order is placed into the right cluster, a machine is queued for creation, and an agent on the host builds it. The service stays Pending while that runs — typically a few minutes — and becomes Active the moment the build reports success. The welcome letter with the generated root password goes out automatically at that point. Watch the build on the Agent Jobs screen; see Agent Jobs and Virtual Machines.

Where a sale is placed on hardware another operator runs, the build happens in their panel and yours waits for confirmation that the machine actually exists. That wait is longer than an ordinary build and is treated as normal until the allowed window expires; only then is the sale reported as failed, and it says plainly that the other operator never confirmed.

Game servers

A container is placed on a game node, its ports are reserved, its files are unpacked and the runtime starts. The service becomes Active and the welcome letter goes out when the container is up — not when it is queued. Watch it from Game Servers; the same cross-panel wait applies to a sale placed on another operator’s node.

Colocation

A rack device is created and rack space is reserved for it against the ordered specification. The service goes Active immediately — there is nothing to install. If rack space could not be assigned automatically the service still activates, and you place it yourself from Rack Management.

The customer is not emailed automatically. Colocation needs hands-on setup before it is usable, so its delivery letter is switched off by default. Turn on Colocation Service Delivered under Settings → Email → Email Triggers if your colocation deliveries need no manual work, or leave it off and use Resend Welcome when the rack work is done. See Email Settings.

IP transit

The ordered address space is allocated in the ordered location and the service goes Active. If the product requires addresses and only part of the request could be satisfied, the partial allocation is released and the service fails rather than activating a transit service with no usable space.

As with colocation, the delivery letter is off by default; the trigger is called IP Transit Service Delivered. The cross-connect and the peering session are still yours to configure — see IP Transit.

Plugin-delivered products

The service’s configuration is handed to the provisioning plugin, which talks to the provider and reports back. On success the service goes Active, the provider’s credentials are stored against it and the welcome letter is sent automatically. On failure the provider’s own error message is recorded on the service.

Two plugin-side settings change this. A plugin whose auto deployment setting is switched off records the delivery as Skipped and waits for you to trigger it. A product pointing at a plugin that is not installed or not enabled fails with a message naming the plugin that is missing. See Introduction to Plugins.

Products bought from a supplier

A product you resell from another panel is ordered upstream and the supplier builds it. Your service reflects what they report.

Watching a delivery happen

The Automations panel

The lightning-bolt icon in the top header is the live view. Every step of every delivery writes a row there — allocation, address assignment, hardware preparation, pre-flight, the provider call, the completion callback — and the list updates within about a second of each step, without a refresh. Rows are colour-coded Success, Pending, Failed, Skipped and Skipped in progress, and clicking a row opens the service behind it. A badge on the icon counts pending and failed runs of the last 24 hours and turns red when any of them failed. This is the single best place to sit while a batch of orders is being delivered. See Automations.

Tip: a row that stays Pending for a virtual machine or game server is not a problem in itself — it means “the build was accepted and is still running”. It becomes Success when the machine is genuinely up. A row that says it is awaiting another operator’s confirmation means the build is happening in a panel you do not control.

The service itself

The service’s status badge is the summary, and the Deploy error box on the Service Information card carries the exact message from the failed step once a service is in Provisioning Failed. That message is the single most useful thing on the page — read it before you retry anything.

Per-module screens

• Agent Jobs lists every queued, running, completed, failed, timed-out and cancelled job for your virtualisation, with the error text and how long each waited. See Agent Jobs.
• Game Servers shows a container’s own creating and installing states.
• The Activity Log records the bookkeeping around a delivery — who retried what, and when an allocation failed.

What retries on its own

A failed delivery is not left alone. Several routines run continuously in the background:

Automatic recovery

Situation	What happens
A service in Provisioning Failed	The delivery is retried automatically, up to three attempts in total, waiting one minute before the second attempt, five before the third and fifteen before the last. After that the platform stops trying.
A paid service stuck at Pending that was never attempted	Picked up after ten minutes and started, provided the order is paid and the product has a real delivery method configured. This catches an order interrupted mid-flight.
A bare-metal service stuck at Installing with no live install running	Re-driven on the same schedule. A genuinely running install is never disturbed.
A hardware node still held by an abandoned operation	Recovered every few minutes, so a crashed operation cannot block every later retry on that machine.
An install that started but never reported back	Detected after an hour and re-synchronised against the machine’s real state, so the screen stops showing an install that is not happening.
A machine that was dispatched but never started booting	Failed after about twenty-five minutes and reverted, so a machine that never came up on the network does not hold the deploy open indefinitely.
A virtual machine or game server sold on another operator’s hardware	Watched for the length of the allowed confirmation window, then settled if the machine appears and failed by name if it never does.
A virtual machine whose build job was reaped although the machine exists	Re-checked against the cluster and settled as delivered when the machine is really there.

Two things are deliberately not retried automatically: anything that has already used its three attempts, and anything that failed for a reason a retry cannot change — an empty hardware pool, an exhausted address range, a plugin that is not installed. Those need you.

The notification you get when a delivery is stuck

When a service uses up its automatic attempts and is still not delivered, the platform stamps the service with Automatic provisioning retries exhausted — retry manually from the service page and raises an admin notification titled Provisioning stuck: service name. The body says the service failed three automatic attempts and needs a manual retry, and the notification links straight to the service. It arrives in the notification bell for administrators. See Notifications.

Tip: this notification is your safety net for a paid order that quietly produced nothing. If you only check one thing after a busy sales day, check that no Provisioning stuck notifications are waiting.

Your recovery controls

Every control that acts on a delivery, and what it costs you

Control	Where	What it does — and the consequence
Retry deployment	Service Details, on a failed service and on a pending service bound to your own hardware	Runs the delivery again. For a service on your own hardware: if it still holds its machine that machine is reused, and if the machine was released by the failure a fresh one is allocated — not necessarily the same one — with addresses re-checked and re-issued. For anything else it simply calls the provider again. Nothing is charged and the customer is not emailed.
Stop deployment	Service Details, on a pending, installing or failed service bound to your own hardware	Aborts an install in flight and releases everything it had taken — the machine back to the pool, the subnet, the addresses, the VLAN and the switch port. The service lands in Provisioning Failed, recorded as cancelled by an administrator. A retry afterwards starts from scratch and may land on different hardware. The confirmation dialog spells all of this out. Use this when a deploy is wedged; do not use it on a healthy install.
Retry Provisioning	Service Details, on a pending plugin-delivered service	Calls the provider again for a service that never got built. Nothing existing is destroyed.
Recreate	Service Details, on a plugin-delivered service that is not pending	Destroys the existing server at the provider and builds a new one, optionally on a different operating system or in a different location, with a root password you supply or one that is generated. All data on the old server is lost. Billing is untouched, and the customer is not emailed — send the new credentials with Resend Welcome. A virtual machine on your own virtualisation cannot be recreated while it is still alive: rebuild it in place with Reinstall, or delete it first.
Retry from the Automations panel	The circular-arrow button on a failed row	Re-runs the action that failed for that service — a suspend as a suspend, a terminate as a terminate, and everything else as a fresh delivery. If a delivery for that service is already running the click is a no-op and says so.
Force recover	Automations panel, beside a row that was skipped because a machine was locked	Clears the lock on that machine at once instead of waiting out the ten-minute countdown shown next to it. Then retry the deploy. Use it only when the countdown has expired or you cannot wait.
Resend Welcome	Service Details, on an active, suspended or pending service	Sends the welcome and credentials letter again, built from whatever is stored on the service right now. If no password is stored, the letter goes out with a placeholder telling the customer to check their panel — so check the credentials card first. This is the normal way to hand over a bare-metal machine, a colocation rack or a transit service.
Edit → Status	Service Details	Sets the service state directly. This is how a manual product is delivered. It changes the record only — it builds nothing and sends nothing.

Finding failed deliveries

The Services list has no filter for failed deliveries. Its status tabs are All, Active, Installing, Suspended, Pending and Cancelled; Provisioning Failed is shown on the badge but is not one of the tabs, and the search box matches names, hostnames, addresses, customers and products — not statuses. To find them:

• Sort by the Status column. Click the Status header on the Services list. Sorting is applied across the whole list, not just the page you are on, so every service in the same state groups together. Click it a second time for descending order and the failed ones sit near the top, just after the terminated and suspended ones.
• Open the Automations panel and look for red Failed rows. Every failed step is there with its error, and each row opens its service.
• Watch your notifications for Provisioning stuck alerts — those are the ones that have already exhausted their automatic retries.
• Filter the list to Pending. A paid service that has sat at Pending for more than a few minutes is as much of a problem as one marked failed, and this is the fastest way to see them.

What the customer sees

While a delivery is running

• Their order shows as placed, and their service appears in their service list straight away.
• A service that is not yet linked to a machine carries a blue notice reading Service Pending Setup, explaining that live statistics and power controls will appear once the service is provisioned.
• A dedicated server they are waiting for shows a Preparing chip with the expected delivery time when the product carries a delivery estimate, or your own override date when you have set one on the service. Without an estimate it shows Processing, and the service page reads Server Preparation in Progress with Processing your order. Delivery estimate will be available shortly.
• They receive nothing else until the service is delivered.

When a delivery fails

The customer sees a red Provisioning Failed badge on their service, in their portal, with no explanation of any kind. The reason recorded on the service is for your staff only and is never shown to them; there is no automatic email telling them what happened or what you are doing about it.

Warning: because the customer sees a failure with no reason, a failed delivery is always a support conversation you should open rather than wait for. Tell them what went wrong in your own words, and give them a time. A customer who paid and is looking at a red badge with no text will otherwise open a ticket, ask for a refund, or dispute the charge.

When it succeeds

The service turns Active, its address, hostname, operating system and location fill in, and the welcome and credentials letter arrives — automatically for plugin-delivered products, virtual machines and game servers, and when you send it for everything else. Once every service on the order is delivered, the order-completed email follows. See Managing Your Services.

Common causes of failure, and how to read the error

The Deploy error box on the service, and the error line on the Automations row, carry the message from the exact step that failed. Read which step it was first — the step name tells you where to look.

Allocation

“No matching device available…” — there is no free machine in that location matching what the customer ordered. Check Inventory for an available unit of the right specification in the right location, or widen the product’s matching rules in Allocation & Equivalences. Nothing was taken, so putting a machine into the pool and retrying is enough.

Address allocation

Messages about subnets or addresses not being available, or about only part of the request succeeding, mean IPAM could not satisfy the order in that location. Add or free address space, then retry. When a partial allocation happened it was released for you, so a retry starts clean.

Pre-flight on bare metal

Pre-flight lists everything wrong at once, separated by semicolons, so one message can carry several faults. The usual ones:

• No operating-system image selected on the order, or none linked to the product as its default. Fix it on the product, or on the service’s captured configuration.
• An image that has not been downloaded yet. Download it from OS Images and retry.
• The machine is missing its provisioning network address, its provisioning interface, or its management address in inventory. Fill those in on the hardware record.
• The bare-metal provisioning service is not enabled or not configured. Start it and complete its settings on the Bare Metal page.
• No provisioning agent for that location, or the agent is offline or out of date. See Local Agents. An agent that is merely behind on its version updates itself and the retry succeeds a minute later.
• The agent is missing a capability it needs to boot a machine over the network. Its installation is incomplete; reinstall it.

Machine busy or locked

A row marked Skipped in progress saying the machine is locked or already deploying means something else is working on that hardware. The panel shows a countdown of about ten minutes; wait for it, or click Force recover and retry.

Virtual machines

Typical causes are no capacity left in the target group, a pinned cluster that is offline, no address left to give the machine, or an operating-system template the plan does not permit. All of these are reported synchronously and land on the service with the reason. Fix the capacity or the template and retry.

Plugin-delivered products

The message is the provider’s own. Authentication failures, quota refusals and unknown plan identifiers all come through verbatim. Check the plugin’s connection settings and its configuration, then retry from the service or from the Automations panel. A message saying no plugin was found for the product’s delivery type means the plugin is not installed or not enabled — install and enable it, then retry.

Add-ons that could not be delivered

An add-on the customer paid for that cannot be applied automatically does not fail the service. Instead a Pending row appears in the Automations panel, from the manual provider, saying that a purchased option needs an operator to deliver it. Apply the resource yourself, then confirm on the service’s options card. See Product Options.

A working routine

1. Open the Automations panel. If the red pill is zero and no Provisioning stuck notification is waiting, nothing needs you.
2. For each red row, click through to the service and read the Deploy error box.
3. Fix the cause — free hardware, address space, an image, an agent, a plugin credential. Retrying without fixing the cause spends your attempts and changes nothing.
4. On bare metal, if the deploy was wedged rather than cleanly failed, click Stop deployment first so everything is released, then Retry deployment.
5. When it comes up, check the machine, then Resend Welcome.
6. Tell the customer. They saw a red badge and no reason.

Related articles

Services · Service Details · Orders · Order Details · Automations · Products · Inventory · IPAM · OS Images · Bare Metal · Local Agents · Email Settings · Upgrades, Downgrades and Proration