Automations
A live header panel showing recent provisioning and service-lifecycle runs — status, errors, retry controls, bulk-fetch progress, and node recovery.
What the Automations panel is for
The Automations panel gives you a live, at-a-glance view of every automated action the platform runs on your behalf — provisioning a new service, suspending or unsuspending it, terminating it, recreating it, and bulk hardware-inventory fetches. Instead of digging through a service one by one, you open one panel to see what just happened, spot failures, and retry them.
How to open it
The panel lives in the top header of the admin area, behind the lightning-bolt icon. On smaller screens where the header collapses, you reach it from the overflow menu (the three-dots icon) as the Automations row. Click the icon to open the dropdown; click anywhere outside it to close.
A small numbered badge appears on the bolt icon when there is new activity since you last opened the panel. The badge is red when there are failures and yellow when there are only pending runs. Opening the panel clears the badge.
Reading the panel
The header of the dropdown shows a rolling 24-hour summary (marked “24h”) as colored pills:
- Ok (green) — runs that completed successfully.
- Pending (yellow) — runs still in progress. This pill only appears when there is at least one pending run.
- Failed (red) — runs that errored. This pill only appears when there is at least one failure.
Below the summary is the list of recent runs, newest first. Each ordinary row shows:
| Element | What it means |
|---|---|
| Status icon | A colored icon on the left: green check (Success), red cross (Failed), yellow clock (Pending), or amber refresh (Skipped / Skipped in progress). |
| Name | The service name. If the service has no label yet, the product name is shown instead; if neither is available it reads Unknown service. |
| Status badge | A pill on the right repeating the status in words: Success, Pending, Failed, Skipped, or Skipped in progress. |
| Action line | The action that ran and which integration handled it, e.g. “Provision via your server platform” or “Suspend via your provisioning integration”. |
| Callback tag | A small blue Callback chip appears when the result came back asynchronously from the provider rather than inline. |
| Timestamp | A relative time such as Just now, 5m ago, 2h ago, or 3d ago. |
| Error preview | Failed rows show the error message in red, truncated to one line. Hover the text to read it in full. |
Common tasks, step by step
Check that your automation pipeline is healthy
- Click the bolt icon in the top header.
- Read the 24-hour Ok / Pending / Failed summary at the top. All-green means nothing needs your attention.
- Scan the list for any red Failed rows and read their inline error.
Retry a failed run
- Find a row with a red Failed badge.
- Click the circular-arrow retry button at the right edge of that row.
- The platform re-runs the original action (provision, suspend, unsuspend, terminate, or recreate) for that service and shows a confirmation toast.
If another run for the same service is already in progress, the retry is safely skipped so no duplicate action is triggered. Before retrying, fix the underlying cause first — most failures trace back to the integration that handled the action (wrong credentials, an unreachable endpoint, or a problem in its flow). Open that integration’s connection settings and correct the issue, then come back here and retry.
Open the service behind a run
- Click anywhere on an ordinary automation row (not the retry button).
- The panel closes and takes you straight to that service’s detail page, where you can inspect its full history and act on it.
Bulk inventory fetches
When you run a bulk hardware-inventory fetch, it appears in the list as a special Bulk Fetch Details entry (marked with a drive icon) rather than an ordinary service row.
While the job is running you see live progress as two bars:
- Step 1: Basic info — the first pass across all devices, with an X / Y device counter and a percentage.
- Step 2: DIMMs, NICs, storage — the deeper detail pass that enriches each device with memory, network, and disk information. This second bar appears once the detail pass begins.
A running line summarizes the outcome so far: how many devices were processed, plus colored counts of ok (green), partial (amber), and failed (red). When the job finishes it shows how long it took.
Inspect and retry failed devices
- On a completed bulk-fetch entry that had failures or partial results, click View details to expand the per-device breakdown.
- Each problem device is listed by name (and IP, if known) with the specific error or warning that occurred.
- If devices outright failed, a Retry N failed button appears. Click it to re-run the fetch for only the failed devices, leaving the successful ones untouched.
Recovering a locked bare-metal node
Bare-metal deployments can occasionally be blocked because the target node is still locked by an operation that is in flight. When that happens, the row shows the Skipped in progress status together with an amber Auto-clears in Nm countdown (up to about 10 minutes), so you know whether to simply wait.
- If you can wait, do nothing — once the countdown reaches zero the lock clears on its own and you can retry the deploy.
- If the countdown has expired (it reads Lock expired — retry now) or you need to unblock urgently, click the Force recover link next to the countdown.
- The platform resets the node back to an available state and shows a confirmation. You can then retry the deployment.
Force recover is an escape hatch — use it only when the node is genuinely stuck. If the original operation is still legitimately working, let the countdown finish instead.
Live updates
The panel refreshes in near-real-time: every time the platform records a new automation step, the list updates within about a second, with no page reload needed. As a safety net, it also re-checks roughly every 30 seconds, so it recovers automatically after a brief network interruption. Bulk-fetch progress bars advance live while the job runs.
Tips and gotchas
- Empty panel — if nothing has run, the panel reads No automation tasks yet. This is normal on a fresh setup.
- A run stuck on Pending usually means a background step stalled. Open the related service to investigate, fix the integration configuration, then retry.
- The badge tracks “new” activity, not unresolved runs — once you open the panel the counter clears, even if some runs shown are still pending or failed. Re-check the panel periodically rather than relying on the badge alone.
- Each run maps to one of your integrations. When something fails repeatedly, the fix almost always lives in that integration’s connection settings or flow, not on this panel.
