> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minenet.pro/llms.txt
> Use this file to discover all available pages before exploring further.

# Run lifecycle and monitoring

> Understand what happens when you apply a configuration, how runs are queued, and how to track outcomes.

Every apply creates or reuses a deployment run for the latest pushed configuration version.

Runs give you a timeline and per-resource visibility, so changes are traceable.

## Before a run is queued

Minenet performs preflight checks, including:

* active subscription,
* plan capacity,
* optional spending limit,
* configuration/team ownership,
* pushed version availability.

If checks fail, apply is rejected early with a clear reason.

Common example: `409 NO_PUSHED_VERSION` when a configuration has never been pushed.

## Queueing behavior

When checks pass, the run is queued and assigned a queue position.

For safety, runs execute in controlled order per team.

## Run status lifecycle

Typical progression:

* `queued`
* `planning`
* `executing`
* `finalizing`
* terminal: `succeeded`, `failed`, `canceled`

## Per-resource action types

During execution, each resource is classified as:

* `create`
* `update`
* `replace`
* `delete`
* `noop`

This explains exactly why Minenet touched (or skipped) each resource.

## Idempotency for automation

If you automate applies through API, use `idempotency_key`.

This prevents duplicate run creation from retries in CI/CD pipelines.

## What to inspect when something looks wrong

1. Run summary status.
2. `configuration_version_id` and `configuration_version_number`.
3. Per-resource action/status rows.
4. Event timeline messages.
5. Final error code/message (if failed).

## Resume behavior

Failed or canceled runs can be resumed.

Use resume after correcting the root cause (for example, quota, validation, or provider-side issue).

## Next step

Continue to [Safe rollouts and troubleshooting](/guides/deployments/safe-rollouts-and-troubleshooting).