Troubleshooting failed installs or updates

Troubleshooting failed installs or updates

This is the full incident playbook for install/update failures, including diagnostics, retry strategy, isolation steps, and escalation data.

Required access: Any customer account running install or update actions.

When to use this troubleshooting flow

Use this immediately after a failed install, failed update, or repeated retry failure in dashboard workflows.

First-response checklist (2-5 minutes)

  1. Confirm the license is active.
  2. Confirm the site is connected.
  3. Confirm the selected product is in your plan.
  4. Confirm no maintenance or lock state is blocking installs.
  5. Retry once after refreshing sessions.

How to troubleshoot

  1. Confirm your license is active and has remaining limits.
  2. Confirm the target website is still connected.
  3. Confirm the product is included in your plan tier.
  4. Retry once after refreshing dashboard and WP sessions.
  5. If still failing, test a different product on the same site.
  6. If that fails, test same product on a different site.
  7. Use this matrix to isolate whether issue is product-specific or site-specific.
  8. Capture failure timestamp and site URL if issue persists.

Isolation matrix

Use two quick tests:

  • Test A: Different product on same site
  • Test B: Same product on different site

Interpretation:

  • A fails + B passes: site issue likely
  • A passes + B fails: product/package issue likely
  • A fails + B fails: account/license/workflow issue likely

What happens after checks

  • Many temporary failures are resolved by reconnecting and retrying.
  • Persistent failures should be escalated with context so support can trace the exact operation.
  • Failed items can often be run individually after fixing root cause.

Escalation template

Provide the following in your support request:

  • Product name
  • Site URL
  • Approximate failure timestamp
  • Expected result
  • Actual result

Related guides

  • How to install plugins and themes from GrootMade Connect
  • How to manage connected websites

Exact route paths

  • /dashboard/history
  • /dashboard/sites
  • /dashboard/support
  • /dashboard/support/new

Expected UI state after each step

  • Step 1: Failed operation is identifiable in recent history.
  • Step 2: Site health can be checked before retry.
  • Step 3: Retry result clearly transitions to success or fail.
  • Step 4: Support form is available for escalation with incident details.

Screenshot map (step-level)

  1. Failure investigation dashboard context

  2. Support escalation context

Operational objective

Complete the “Troubleshooting failed installs or updates” workflow with predictable outcomes, clear auditability, and repeatable execution quality across team members and projects.

Acceptance criteria (all must pass)

  • The workflow can be completed without missing permissions or blocked route access.
  • All required dashboard routes load successfully for the active account.
  • The expected UI states are visible in the same order as documented.
  • At least one end-to-end validation confirms the process works in practice.
  • Evidence artifacts are captured for support and audit handoff.

Routes that must be reachable during validation:

  • /dashboard/history
  • /dashboard/sites
  • /dashboard/support
  • /dashboard/support/new

Failure modes and exact remediation

  • Permission failure: Recheck plan/license entitlements and retry after session refresh.
  • Route loads but action is missing: Confirm feature flags/plan gates and selected context (site/license).
  • Action runs but state does not update: Refresh, re-open the relevant page, and verify from history/log view.
  • Partial success in multi-step operations: Retry only failed sub-steps and preserve successful state.
  • Cross-page mismatch: Reconcile with dashboard history and capture timestamps before escalation.
  • Persistent failure after one controlled retry: Open support ticket with full evidence package.

Evidence package for support escalation

Collect all items before escalating:

  • Account email and user role
  • Affected route path and exact action taken
  • Site URL, product/license identifier (if relevant)
  • Timestamps for first failure and latest retry
  • Expected result vs actual result
  • Screenshot set listed below

Screenshot evidence checklist

  • Step 1: Failure investigation dashboard context
  • Step 2: Support escalation context
  • One screenshot with visible timestamp (system clock/browser tab)
  • One screenshot showing route context or breadcrumb
  • One screenshot showing final persisted result
  • Replace any generic placeholder/demo visuals with real environment captures

FAQ

Can I skip steps if I already know this workflow?

Skip only after all acceptance criteria still pass. If any criterion fails, run the full sequence exactly as documented.

Should I run this in production first?

Use staging first for medium/high-impact changes. Promote to production only after validation evidence is complete.

What if my screen does not match the guide exactly?

UI can vary by plan and feature access. Validate route access, plan gates, and expected state outcomes instead of pixel-perfect layout.

How many retries should I perform before escalation?

Run one controlled retry after checklist validation. If failure persists, escalate with full evidence to avoid hidden side effects.

Who owns this guide operationally?

Support Engineering owns this guide and its periodic review cycle.

Guide metadata

  • Difficulty: Advanced
  • Estimated completion time: 20-40 minutes
  • Owner: Support Engineering
  • Last reviewed: 2026-03-18