Part 8 — Monitoring
On this page 10 headings
Why monitor after deployment?
Section point: Even after thorough testing in the testing and staging environments, issues can still arise in the live environment. The application must therefore be constantly monitored once deployed.
What to monitor (lecture)
- CPU utilisation: how it behaves, especially at peak times.
- Memory utilisation.
- Storage: consumed vs free. If database-heavy activity fills the disk, nothing new can be added to the database, and users start getting errors.
- Network bandwidth and latency. Latency is the time it takes for a user to get a response. Check periodically that it is not getting worse.
Monitoring tools — 1: Reporting tools (Lighthouse)
Reporting tools generate reports. You give them a URL, and they:
- analyse the page’s resources,
- give optimisation suggestions,
- check metrics such as SEO and accessibility, and
- calculate a performance score for the website.
Section point: Lighthouse is a tool provided by Google. The lecture describes it as a Google Chrome extension that you can install to check the performance scores of websites. The lecture demonstrates it on the verisim.tech website, showing metrics such as how long the page takes to load and the Speed Index.
Monitoring tools — 2: Understanding customer behaviour
Monitoring is not only about servers. Another important reason to monitor is to understand how customers behave. These ideas belong to web analytics.
The lecture names three things to monitor.
(a) Clickstreams
Section point: Clickstreams answer the question: which sequences of pages do your users visit the most? A website offers many possible paths, and clickstream analysis shows which paths users actually take most often.
(b) Think time / Dwell time
Section point: Think time or dwell time is how long a typical user stays on a given page.
(c) Abandonment
An application has flows: sequences of steps that lead to a goal. The lecture’s example is a purchase flow:
Product page → Buy Now → Add address → Add payment details → Pay
Section point: Abandonment = the percentage of users who “abandon” a flow instead of completing it.
Completing the flow is the desired path for the business. Abandoning it partway means lost business from that customer, which is why abandonment is an important metric to monitor.
Analytics tools — Google Analytics
Section point: Analytics tools work by embedding a small piece of JavaScript in every page of your website. This snippet contains a tracking code, and it sends information to the analytics tool each time the page is loaded. Google Analytics is the example. It shows metrics such as what happens after each interaction and where users drop off. To use it, you sign up for an account and insert the tracking code into your website.
Monitoring for A/B testing
Suppose version A of your website has a problem. For example, abandonment is high. To fix it you create version B, with a new workflow or a better UI.
How do you know whether B is actually better? The lecture’s answer is to:
- Use a canary deployment (phased / incremental rollout), so that some users get version A and other users get version B.
- Monitor both versions and check which one is better.
“Better” can be measured as more traffic, more dwell time on a page, more sales, less abandonment, and so on.
Section point: Monitoring is useful for A/B testing: checking whether the new version of your application is better than the previous one. In the lecture, the A/B split is done using a canary-style incremental rollout.
Summary of Parts 7 and 8
| Topic | Key facts |
|---|---|
| Caching | Store results of common operations in memory; reduces server load; Memcached, Redis; levels: browser, web server (page cache), database (query cache) |
| Task queues | For time-consuming tasks (bulk emails, bulk DB updates); asynchronous, outside the HTTP request–response cycle; queue of jobs + parameters, pool of workers; workers can be increased dynamically |
| Fast loading | Matters for users (stress) and business (AliExpress 30% faster → +10.5% orders; Google +0.5 s → −25% requests); minify code (~41% saved in example); compress with Gzip/Brotli |
| What to monitor | CPU, memory, storage (consumed vs free), network bandwidth, latency |
| Reporting tools | Lighthouse (Google): page resources, suggestions, SEO, accessibility, performance score |
| Customer behaviour | Clickstreams (most common page sequences), think/dwell time (time on a page), abandonment (% who leave a flow) |
| Analytics tools | JavaScript tracking code embedded in every page; e.g. Google Analytics |
| A/B testing | Version A vs B rolled out via canary; monitor which is better (traffic, dwell time, sales, abandonment) |