# Create a log record when an action starts, and show its live status and output

**Project:** Panel | **Votes:** 1
**URL:** https://roadmap.ploi.io/projects/3-panel-requests/items/1655-create-a-log-record-when-an-action-starts-and-show-its-live-status-and-output

---

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.