When I run an action from the panel (a command, a backup script, a deployment, ...), its entry in the logs page (Site → Logs / Server → Logs) is only created once the run has fully completed. Until then there is nothing to look at.

When Ploi's queue is busy, this makes it impossible to tell:

1. whether the action has been queued at all;
2. whether it has started running;
3. what it is doing right now (no live output, unlike the deployment log on the site overview, which already streams);
4. whether it is still processing or has finished.

You click "Run", get a toast, and then wait without knowing whether to wait longer, retry (and risk running it twice) or contact support.

Proposal:

Create the log record as soon as the action is triggered, and update it as the action moves through its lifecycle:

• queued: record created, with who triggered it, when, and what (command/script/deployment);
• running: picked up by a worker, with a start time;
• live output: stdout/stderr streamed into the record while it runs, the same way the deployment log already does;
• finished: completed or failed, with an end time, duration and exit code.

In the panel:

• Show the record immediately in the logs list with a status badge (Queued / Running / Completed / Failed), and auto-refresh it.
• Give each record a stable URL, so you can link to it directly (from a notification, a ticket or a colleague) and open it while it is still running.
• The toast after clicking "Run" could link straight to that record.

API / CLI:

• Return the log record ID in the response when an action is triggered.
• Expose an endpoint (and a CLI command, e.g. ploi logs:show <id> --follow) to poll the status and stream the output, similar to the existing logs:stream for deployments.

Why this matters:

• During busy periods you can see that an action is queued instead of wondering whether the click registered, which prevents duplicate runs of non-idempotent commands (migrations, backups, cache clears).
• Long-running scripts can be monitored live, and a hanging or failing step is visible right away instead of only afterwards.
• It makes automation possible: trigger an action through the API or CLI, then wait for the result and act on it, without guessing with timeouts.
• It brings commands and scripts in line with deployments, which already work this way.