What Should You Monitor on a Website and Application? A Practical Checklist from Uptime to Errors and Performance

CPU, RAM, load average, containers, processes, requests, errors, logs, queues, databases, DNS, SSL, APIs, uptime, response times, Core Web Vitals, and much more.

The problem is that monitoring more metrics does not automatically mean better monitoring.

In practice, the most important thing is detecting problems that actually affect users or your business.

So instead of starting with the question:

"What can we measure?"

it's better to ask:

"What problems do we want to know about before our customers tell us?"

1. Is the website actually available?

This is the most basic level of monitoring.

An external monitoring system regularly sends a request to the website and checks whether it receives a valid response.

It can detect issues such as:

• HTTP 500,
• HTTP 502,
• HTTP 503,
• timeouts,
• connection failures,
• DNS issues,
• broken redirects.

This is classic uptime monitoring.

If the website is checked every minute, a problem can potentially be detected within about a minute instead of waiting for someone to visit the website and report the outage.

But uptime is only the beginning.

2. Is the website responding fast enough?

A website can be available and still be very slow.

That's why it's worth recording the response time with every check.

Let's assume the application normally responds in:

250-400 ms

Then suddenly starts responding in:

1.8-3.5 s

We don't have a complete outage yet.

But there is a clear change in the system's behavior.

Possible causes include:

• server overload,
• database issues,
• slow external APIs,
• exhausted workers,
• cache problems,
• changes introduced in the latest deployment.

Response time monitoring can therefore detect a problem earlier than a standard downtime alert.

3. Is the performance degradation temporary or persistent?

One slower request does not necessarily mean there is a problem.

The internet is not a completely deterministic environment.

Instead of reacting to every individual anomaly, it's better to analyze behavior over time.

For example:

10:00 - 320 ms
10:01 - 340 ms
10:02 - 310 ms
10:03 - 870 ms
10:04 - 350 ms

A single 870 ms request is probably not a reason for an alert.

But:

10:00 - 320 ms
10:01 - 510 ms
10:02 - 840 ms
10:03 - 1.3 s
10:04 - 2.1 s
10:05 - 3.4 s

already shows a clear trend.

Good monitoring should help distinguish temporary anomalies from real service degradation.

4. Is the SSL certificate valid?

An SSL certificate is one of the easiest things to monitor.

And at the same time, one of the easiest things to forget about.

A certificate problem can cause users to see a security warning instead of your website.

For an online store or application, this can effectively stop traffic.

That's why monitoring should check:

• whether the certificate is valid,
• when it expires,
• whether the certificate matches the correct domain,
• whether an HTTPS connection can be established correctly.

The biggest advantage of this type of monitoring is the ability to react before an outage.

You don't have to wait until the certificate expires.

An alert can be sent well in advance.

5. Is the application generating errors?

External monitoring shows the application from the user's perspective.

Error monitoring shows it from the inside.

If the application generates an exception:

PaymentException

or:

DatabaseConnectionException

it's worth knowing about it regardless of whether the homepage still returns HTTP 200.

The error message alone is often not enough.

Diagnostic context is much more useful:

• where the error occurred,
• when it first occurred,
• when it occurred most recently,
• how many times it occurred,
• which application version was deployed,
• which endpoint was being executed,
• the stack trace,
• whether the number of occurrences is increasing.

This allows you to move from:

"We have an error."

to:

"We know where to start looking for the cause."

6. Not every error is equally important

Let's assume the system recorded two exceptions.

The first:

5 occurrences over 30 days

The second:

5,000 occurrences in the last 20 minutes

Technically, both may represent exactly the same type of exception.

Operationally, however, they are completely different situations.

That's why error monitoring should not only answer:

"What error occurred?"

but also:

"How is the frequency of this error changing?"

A sudden increase in errors after deploying a new version can be much more important than the fact that a particular exception exists.

7. Did the latest deployment break something?

One of the most valuable uses of monitoring is observing the application immediately after deployment.

Imagine:

14:02 - deployment version 2.18.4
14:05 - first new errors
14:07 - 120 errors
14:10 - 640 errors

Without information about the application version, we only see an increase in errors.

If monitoring knows the release version, we get much more context:

Problems started a few minutes after deploying version 2.18.4.

This does not automatically mean that the deployment caused the problem.

But it is a very important diagnostic clue.

8. Is the website fast for the user?

Server response time and website performance in the browser are not the same thing.

The server may return HTML in 150 ms, while the website still needs to load:

• large images,
• JavaScript,
• fonts,
• ads,
• analytics scripts,
• external widgets.

That's why it's also worth monitoring website performance.

One of the standard benchmarks is Core Web Vitals.

LCP - Largest Contentful Paint

Measures how quickly the main content element of the page appears.

INP - Interaction to Next Paint

Measures how responsive the page is after a user interaction.

Clicking a button, selecting an option, or entering data can feel "broken" if the browser responds with a significant delay.

An INP of 200 ms or less at the 75th percentile is considered good.

CLS - Cumulative Layout Shift

Measures unexpected movement of elements while using the page.

For example, a user wants to click:

Buy Now

but just before the click, a banner loads above it and moves the button to another position.

This is exactly the type of problem CLS helps measure.

9. Why should you monitor performance regularly?

A one-time PageSpeed test is useful.

But a website does not remain unchanged.

You may add:

• a new banner,
• a new marketing script,
• an additional analytics tag,
• a new application version,
• a new JavaScript library,
• larger product images,
• new fonts,
• a new chat widget.

Any of these changes can reduce performance.

That's why a more useful question than:

"What's our PageSpeed score today?"

is:

"Is our website's performance getting worse over time?"

Monitoring allows you to see the trend.

10. Should you monitor only the homepage?

Usually not.

The homepage is typically only one of many types of pages.

For an online store, it's worth considering monitoring:

/
/product/example
/category/example
/cart
/checkout

For a SaaS application:

/
/login
/register
/dashboard

as well as the most important API endpoints.

The goal is not to monitor every URL in the same way.

The goal is to select representative critical points.

11. What should you monitor in an online store?

A reasonable minimum setup may include:

Store Availability

Is the store responding?

Response Time

Has the store suddenly become significantly slower?

SSL

Is the certificate valid, and is its expiration date approaching?

Application Errors

Is WooCommerce, PrestaShop, or a custom backend generating new errors?

Checkout

Is the critical part of the purchasing process available?

Performance

Have Core Web Vitals or other performance metrics degraded after recent changes?

Critical Integrations

If sales depend on external services, problems may also affect:

• payments,
• ERP,
• inventory systems,
• shipping providers,
• marketplaces,
• external APIs.

The store may be technically online while still being unable to process orders correctly.

12. What should you monitor in a SaaS application?

For SaaS applications, the priorities may be slightly different.

It's worth monitoring:

• the public website,
• sign-in,
• the API,
• backend errors,
• the most important business processes,
• response times,
• background jobs,
• queues,
• external integrations,
• SSL,
• frontend performance.

It's especially important to monitor the features users are actually paying for.

If the dashboard works but the product's main feature has stopped working, the application has a serious outage from a business perspective.

13. Monitoring should answer questions, not produce data

It's easy to build a dashboard containing:

47 charts
23 metrics
15 status indicators
8 tables

and still not know whether the application is working correctly.

Good monitoring should let you quickly answer a few simple questions:

• Is the application available?
• Is it responding as fast as usual?
• Have new errors appeared?
• Has the number of errors suddenly increased?
• Is the SSL certificate valid?
• Has website performance degraded?
• Are the most important business functions working?

If monitoring doesn't help answer these questions, collecting more data will not necessarily solve the problem.

14. Where should you start?

You don't need to build a complex observability system from day one.

For many websites and applications, a sensible starting point is monitoring four areas:

1. Uptime - is the service available?
2. Errors - is the application generating exceptions, and is their number increasing?
3. SSL - is the certificate valid, and is it approaching expiration?
4. Performance - is the website still performing as well as before?

More detailed monitoring can be added later depending on the type of application.

The Most Important Monitoring Principle

Monitoring should not exist just to have a dashboard.

It should reduce the time between a problem occurring and the right person finding out about it.

Even better if it can detect a deteriorating situation before it becomes a complete outage.

The worst-case scenario is not always an application that has stopped working completely.

Sometimes it's much worse when an application has not been working correctly for several hours and its owner still doesn't know about it.