Cookie settings

We use cookies

Necessary cookies keep the website working and store your choice. With your consent, we can also use functional cookies to remember the theme preference and analytics cookies to measure website usage.

You can accept optional cookies all at once, reject them, or choose individual categories. You can change your consent later; details are available in the Cookies Policy.

LaraDep Documentation

You are reading Managed mode

Troubleshooting for managed mode

Practical playbook for handling issues in managed mode: what to do when a run fails, how to keep audit trace, and how to restore stable operations quickly.

Troubleshooting for managed mode

Managed mode focuses on stability, but failures still happen: wrong inputs, temporary connectivity issues, or unexpected runtime state. This page is your operational playbook when a deployment fails or results differ from intent.

Purpose and prerequisites

  • Purpose: quickly stabilize operations, identify root cause, and keep full run evidence for auditability.
  • Prerequisites: onboarding completed, access to run history, and clear team ownership model.
  • Needed inputs: run ID, workspace context, and latest logs.

Step-by-step response

  1. Pause further changes immediately — do not launch additional runs against the same target during the incident.
  2. Confirm scope and ownership — who launched it, from which workspace, and with which template stack.
  3. Review preflight and logs — preflight failures usually identify the root faster than deep runtime logs.
  4. Assess impact — is it a partial function issue or a production regression?
  5. Choose recovery path — fix required values, re-run, or execute controlled rollback.
  6. Record decision — add run comments with owner, reasoning, and chosen remediation.
  7. Prevent repeat failures — update onboarding and runbook checks where needed.

Execution checklist

  • Do you have the correct run ID and workspace validated?
  • Are logs available before and after the failure?
  • Was the run triggered outside approved ownership and window?
  • Is rollback path available and tested?
  • Is incident context fully recorded in the change history?

Common mistakes

  • Starting the next run before fully investigating the previous failure.
  • Retrying without addressing root cause warnings.
  • Missing audit details in runbook and workspace history.
  • Unclear role ownership for incident decisions.

Next steps

Next step: Continue with managed operations, then validate runbook.

Subscribe to our Newsletter

Stay updated with our latest news and articles by subscribing to our newsletter.

Esc Close