FluxDeployDocs
Topics: Deployment Activity

Deployment Activity

Activity > Deployments (/activity/deployments) is the shortest path from "a machine was just imaged" to "here is its log, in a file I can email".

It lists the 50 most recent deployments, newest first. Each row carries the machine (hostname, MAC and serial), the deployment status, when it happened, which relay site deployed it, and the recipe that was applied. Failed deployments are tinted red and carry the agent's last status message under the status, because a failure is what people usually open this tab to find. The Failed only button narrows the list to those rows in one click, and the search box matches hostname, MAC or serial.

Machines that have never started a deployment do not appear here - this is a list of deployments, not an inventory. For the full fleet, including devices that have only ever checked in, use Reports > Machines.

Viewing a machine's log

Press View on any row to open that machine's deployment log at /activity/deployments/{id}. The address is stable, so it can be pasted to a colleague.

Where the log comes from depends on who did the deployment:

  • Deployed by a relay site. FluxDeploy asks that relay for the log live, over a pinned HTTPS connection authenticated with the site's API key. The relay is the only place these lines exist, so the relay has to be reachable at the moment you press View.
  • Deployed by Core itself. The agent posted its lines straight into this server's database, so they are read locally and are always available.

The filter box above the log narrows it to lines containing a piece of text. It also narrows what Copy and Download .txt produce, so you can export just the failing phase rather than the whole run.

Getting the log out of the browser

  • Copy puts the log on the clipboard as plain text.
  • Download .txt saves it as fluxdeploy-{machine}-{timestamp}.txt.

Both produce the same text, with a header naming the machine and the export time, then one line per entry as [timestamp] [level] message. That header matters once the file has left FluxDeploy - a bare wall of timestamps in a support ticket is not attributable to anything.

Refresh re-runs the pull. On a relay-deployed machine that is a fresh request to the relay, so it picks up lines written since the page was opened.

When the log cannot be fetched

A relay that cannot answer produces a short explanation rather than an error page. The common ones:

Message What to do
The relay is Unreachable, Disabled or Pending Check the site on Sites. Logs are pulled live, so the relay has to be online.
The relay has no stored API key on this server Re-register the relay from Sites to issue a new key.
The relay could not be contacted securely The site has no pinned TLS thumbprint yet. It is recorded on the relay's first heartbeat, so let the relay check in once.
The relay rejected this server's API key Re-register the relay from Sites.
That machine is no longer in the database The data retention policy removed it. See Settings > General > Data Retention.
  • Reports > Machines - the whole fleet, with hardware and filtering.
  • Machine detail - one device's full record, including its Core-side deployment log entries.
  • Activity > Server Logs - this server's own log files, and a relay's, by category.