Site performance, purge, and cache issues

Use the following list to identify and troubleshoot issues related to the Fastly service configuration for your Adobe Commerce on cloud infrastructure environment.

  • Store menu does not display or work—You might be using a link or temp link directly to the origin server instead of using the live site URL, or you used -H "host:URL" in a cURL command. If you bypass Fastly to the origin server, the main menu does not work and incorrect headers display that allow caching on the browser side.

  • Top navigation does not work—The top navigation relies on Edge Side Includes (ESI) processing which is enabled when you upload the default Magento Fastly VCL snippets. If the navigation is not working, upload the Fastly VCL and recheck the site.

  • Geo-location/GeoIP does not work— The default Magento Fastly VCL snippets append the country code to the URL. If the country code is not working, upload the Fastly VCL and recheck the site.

  • Pages are not caching—By default, Fastly does not cache pages with the Set-Cookies header. Adobe Commerce sets cookies even on cacheable pages (TTL > 0). The default Magento Fastly VCL strips those cookies on cacheable pages. If pages are not caching, upload the Fastly VCL and recheck the site.

    This issue can also occur if a page block in a template is marked uncacheable. In that case, the problem is most likely caused by a third-party module or extension blocking or removing the Adobe Commerce headers. To resolve the issue, see X-Cache contains only MISS, no HIT.

  • Purge requests are failing—Fastly returns the following error when you submit a purge request:

    The purge request was not processed successfully.
    

    This issue can be caused by either of the following issues:

    • Invalid Fastly credentials in the Fastly service configuration for the Adobe Commerce on cloud infrastructure project environment
    • Invalid code in a custom VCL snippet

    To resolve the issue, see Error purging Fastly cache on Cloud in the Adobe Commerce Help Center.

503 errors from Fastly

If Fastly returns 503 timeout errors, check the error logs and the 503 error page to identify the root cause.

NOTE
If the timeout occurs when running bulk operations, you can extend the Fastly timeout for the Admin.

If you receive a 503 error, check the Production or Staging environment error log and php access log to troubleshoot the issue.

To check the error logs:

  • Error log

    /var/log/platform/<project-ID>/error.log
    

    This log includes any errors from the application or PHP engine, for example memory_limit or max_execution_time exceeded errors. If you do not find any Fastly related errors, check the PHP access log.

  • PHP access log

    /var/log/platform/<project-ID>/php.access.log
    

    Search the log for HTTP 200 responses for the URL that returned the 503 error. If you find the 200 response, it means that Adobe Commerce returned the page without errors. That indicates the issue might have occurred after the interval that exceeds the first_byte_timeout value set in the Fastly service configuration.

When a 503 error occurs, Fastly returns the reason on the error and maintenance page. You might not be able to see the reason if you added code for a custom response page. To view the reason code on the default error page, you can remove the HTML code for the custom error page.

To check the Fastly 503 error page:

  1. Log in to the Admin.

  2. Click Stores > Settings > Configuration > Advanced > System.

  3. In the right pane, expand Full Page Cache.

  4. In the Fastly Configuration section, expand Custom Synthetic Pages as the following figure shows.

    Custom 503 error page

  5. Click Set HTML.

  6. Remove the custom code. You can save it in a text program to add back later.

  7. Click Upload to send your updates to Fastly.

  8. Click Save Config at the top of the page.

  9. Reopen the URL that caused the 503 error. Fastly returns an error page with the reason as shown in the following example.

    Fastly error