Adobe Commerce Cloud bugs, fixed properly

Three fixed-price tiers, no per-hour surprises: Quick Fix $99 (~4h @ $25/hr) for one well-defined Cloud bug fixed in 24–48h; Bug-Fix Sprint $499 (~20h @ $25/hr) for a batch of bugs or one deep root-cause with regression tests; and Emergency / Retainer (custom) for 24/7 on-call cover, including an optional $2,499 stabilization sprint (~100h @ $25/hr). You get the price before any work starts.

Yes. A failed Cloud deploy almost always shows up as an ece-tools error in var/log/cloud.log or deploy.log — a bad .magento.env.yaml setting, a config-import mismatch, or a patch that won’t apply (“Unable to apply patch”). We read the logs, reproduce on your Integration branch, fix the root cause, and get the pipeline green again. Most single deploy failures are a Quick Fix.

On Adobe Commerce Cloud, Fastly is the full-page cache. If edits don’t show, the usual causes are: surrogate keys not being purged, a stale-while-revalidate window, a broken custom VCL snippet (often throwing a 503), or the Fastly module not being configured for soft-purge. We audit your Fastly setup, fix the VCL or purge logic, and confirm that price, stock and CMS changes invalidate correctly.

Yes — that’s the whole point of staging-first. On Adobe Commerce Cloud we reproduce and fix on your Integration or Staging branch, never debugging Production directly. You review the diff and the green pipeline, then we promote Staging → Production through the standard Cloud deploy. Every fix ships with 14 days of free regression cover if anything regresses from our change.

Staging first, always. Adobe Commerce Cloud gives every project an Integration, Staging and Production environment, and we use that workflow exactly as Adobe intends: reproduce on Integration/Staging, fix on a feature branch, verify the pipeline, then promote to Production. For true emergencies where the bug only manifests on Production, we work on a clone or behind maintenance mode with your sign-off — never blind changes on live.

Emergency Production incidents are triaged within 4 business hours (under 1 hour on a retainer). A single, reproducible bug is typically fixed and deployed in 24–48 hours. A deeper root-cause spanning deploy, Fastly, B2B and config-management usually lands inside a Bug-Fix Sprint of a few working days, including the regression tests.

Ideally: a user added to your Adobe Commerce Cloud project (Integration/Staging at minimum), read access to cloud.log / deploy.log, and a New Relic APM link if you have one. For Fastly issues we need the Fastly service ID and API token (or admin access to configure it through the Cloud admin). If you can’t grant project access immediately, we can start from logs and a screen-share and arrange access in parallel.

Yes — post-patch regressions are one of the most common Adobe Commerce tickets. After a quarterly security patch or version bump, you might see a PHP Fatal error, a New Relic error-rate spike, or a third-party extension that no longer applies cleanly. We diff the patch against your customizations, pin the conflict, and ship a verified fix that survives the next patch cycle. A backlog of post-patch issues fits a Bug-Fix Sprint.

Yes. B2B is where Adobe Commerce earns its licence and where bugs hide: shared-catalog prices not applying to a company, the requisition-list or negotiable-quote workflow stalling, or company-account credit limits miscalculating. We trace the issue through the B2B module, the shared-catalog indexer and the relevant price scopes to a clean root-cause fix — not a workaround.

That’s configuration drift. On Adobe Commerce Cloud, config lives in three places: app/etc/config.php (committed), environment variables (per-environment), and the database. When they fall out of sync, a setting applies on Staging but not Production. We diff the two environments, identify which layer drifted, and bring everything back under bin/magento config:dump / config-management control so it deploys deterministically.

Yes. A long deploy phase means real downtime on each release. The usual fixes: move static-content deployment into the build phase, tune SCD_THREADS and SCD_MATRIX in .magento.env.yaml, trim unused locales, and enable the post-deploy warm-up hook. We typically cut multi-minute maintenance windows down to seconds while keeping the pipeline reproducible.

Yes. Every fix ships with 14 days of free regression cover — if anything regresses because of our change, we fix it at no extra charge. We also commit an automated regression test to your repo for each substantive bug so it can’t silently come back on the next deploy. For ongoing peace of mind, a retainer adds reserved hours and a tighter SLA. Read more on the emergency bug-fixing hub.