🎉 Welcome to the Mobify DevCenter, our new home for v2.0 documentation and developer resources! (For now, the site is desktop-only.) Switch to old site
Mobify DevCenter
DocumentationAPI & SDK ReferenceHow-To Guides

Monitoring Your Site After Launch

What should you track?

  • Cache hit ratios: post-launch is a great time to optimize cache hit ratios. Do this by adjusting your application’s cache headers for each page type.

    For example, you may set a cache header to 1 hour for the home page, and 4 hours for a category listing page. In general, you can start by setting cache headers to 1 hour. Reach out to your Mobify contact for help in setting the optimal cache headers.

    Continue to track cache hit ratios and update them as your site’s content and traffic changes. (Do this weekly, or even daily.) To learn more about setting cache headers, read our how-to article on using the CDN.

    Note: Talk to your Mobify contact to access a dashboard tool for cache hit ratios.

  • Response time: this is a key indicator of your site’s performance. Keep tabs on the response time for any requests that go through the proxy. (That could be your backend, CMS system, and the PWA’s total server-side rendered response time.) It’s best to look at response times from several different angles to understand the full picture.

    For example, you can look at response times by percentile. The 50th percentile will display the median response time. Then, the 95th and 99th percentiles will show you the worst case response times. You can also track response times by cache hit type. For example, you can filter to look only at cache misses.

    Backend performance will vary over time, so it’s important to continue monitoring. Track response times each day for general monitoring, or by the hour for specific issues. Your response times will decrease as you tweak your cache header values. If not, you have the harder task of understanding why through logging and profiling.

  • HTTP status codes: this will allow you to find and fix common errors, like HTTP 400 and 500 errors. This is ideal both immediately after launch and in ongoing monitoring.

    Note: 404 errors don’t always mean something went wrong. For example, a 404 error is the correct response when a user visits a URL for a page that doesn’t exist.

  • Backend error rates: this will allow you to plan safe outage states for system failure. For example, some ecommerce backends go down every 28 days for routine maintenance. Knowing your application’s backend behavior will help you handle backend outages.

What should you log?

Do log:

  • Errors and Exceptions, to help you investigate when issues occur.
  • Poor performance. Log when key business functions perform below expectations, like your application’s checkout flow.

Don’t log:

  • Personally identifiable information, to ensure compliance with PCI security standards.
  • Credit card information.
  • Try to keep your logs at a bearable volume. Log enough so that you can have a good picture of what’s going on, but avoid logging everything. If you log too much information, you’ll need to spend time filtering to make your logs more manageable.