Monitoring and Observability

When a business system slows down or fails, the first question is always the same: what happened, and when did it start? Monitoring and observability are how you answer that question quickly enough to limit the damage. They are not the same thing, though the terms are often used interchangeably. Monitoring tells you whether something is working. Observability lets you work out why it is not.

For anyone buying, building or running a CRM, portal, internal tool or SaaS product, these are not optional extras. They are operational necessities that affect how fast problems are found, how much downtime costs, and whether your team or supplier can fix issues before users notice them.

How to Monitor a Web Application

Monitoring a web application means instrumenting it at several layers so that failures and degradation are visible. The practical starting point is to decide what "working" looks like for your specific system, then measure against that definition continuously.

The layers that matter

Most business applications need visibility at four levels:

• Infrastructure — server CPU, memory, disk space and network throughput on the machines hosting the application.
• Application — response times, error rates and throughput for key endpoints or pages.
• Dependencies — the databases, external APIs and third-party services the application relies on.
• Business processes — whether critical workflows such as order submission, document generation or user onboarding are completing successfully.

A common mistake is to stop at infrastructure. A server can be perfectly healthy while the application is returning errors because a database connection has been exhausted or an integration has started rejecting requests.

Getting started without overcomplicating things

For smaller internal tools, a basic setup might include a simple uptime check that hits a key page every minute, combined with server-level metrics from your cloud provider's built-in dashboards. For customer-facing SaaS products or systems processing high-value transactions, you will want application-level instrumentation from day one, because retroactively adding it is significantly more disruptive.

The practical question to ask a supplier is: "What exactly will we be able to see when something goes wrong, and how quickly?" If the answer is limited to server health, push further.

Application Performance Monitoring Explained

Application Performance Monitoring, usually abbreviated to APM, focuses on how the application itself behaves under load. It tracks metrics such as how long requests take to complete, how many requests are being handled per second, and what proportion of those requests result in errors.

Unlike basic infrastructure monitoring, APM traces the path of a request through the application. If a customer portal page takes eight seconds to load, APM can show whether the delay happened in the database query, an external API call, or the application's own logic. That distinction changes the fix entirely.

What APM actually measures

• Response time distribution — not just the average, but the slowest requests. An average of 400 milliseconds can hide a tail of requests taking several seconds.
• Error rate by endpoint — which specific pages or API routes are failing, and at what volume.
• Throughput — how much traffic the application is handling, which helps correlate performance dips with load spikes.
• Dependency latency — how long the application waits on databases, caches and external services.

For business systems, the value of APM is not technical elegance. It is the difference between a support team saying "the system is slow" and being able to say "the system is slow because the reporting module is making unoptimised database queries, and it started after the latest release."

Uptime Monitoring vs Performance Monitoring

These two concepts are often conflated, but they catch different problems. Understanding the distinction helps you avoid a false sense of security.

Uptime monitoring checks whether a service is reachable and returning a valid response. A simple ping or HTTP request is made at regular intervals. If the service does not respond within a timeout, or returns an error code, it is marked as down. This catches outright failures: crashed servers, misconfigured firewalls, expired domains and deployment errors that bring the application offline entirely.

Performance monitoring measures how well the service is working when it is up. It tracks response times, slow queries, memory usage trends and error rates that fall below the threshold of a full outage. A portal that takes twelve seconds to load a customer's documents is technically up, but from a business perspective it is effectively broken.

Both are necessary. Relying solely on uptime monitoring means you will not notice performance degradation until users complain. Relying solely on performance monitoring means you might miss a complete outage if the monitoring agent itself loses connectivity.

How to Set Up Alerts for Web Application Issues

Alerts are only useful if the right people receive the right information at the right time. Poorly configured alerting is often worse than no alerting at all, because it trains teams to ignore notifications.

Defining severity levels

A practical approach is to define alert severity against business impact, not technical thresholds:

• Critical — the system is down or a core business process is completely broken. Someone needs to act immediately, regardless of the time.
• High — a significant degradation affecting many users or a key workflow. Action is needed promptly, within a defined service window.
• Medium — a non-critical function is impaired or error rates are elevated but not yet at a level that visibly affects most users. Investigation should happen during working hours.
• Low — informational. A trend worth noting but not requiring immediate action.

Common alerting mistakes

Alerting on every metric threshold is the most frequent error. If CPU usage briefly spikes to 85% during a routine batch process and triggers a critical alert at 2 a.m., the on-call engineer will quickly learn to silence notifications. Alerts should be based on sustained conditions that correlate with real problems, not momentary fluctuations.

Another mistake is sending all alerts to the same channel. A critical outage and a minor increase in 404 errors should not compete for attention in the same Slack channel or email inbox. Route by severity and by the team best placed to respond.

When agreeing alerting with a supplier, ask specifically: "How many alerts does a typical client receive per week, and what proportion of those represent genuine issues requiring action?" If they cannot answer, the alerting is likely not well-tuned.

Log Management for Business Applications

Logs are the detailed record of what an application has done. Every request, error, authentication event and integration call can produce a log entry. For business systems, logs are essential for three purposes: diagnosing problems, investigating security events, and meeting compliance obligations.

What makes logs useful

A log entry that says "Error occurred" is worthless. A useful log entry includes context: which user was affected, which action they were performing, what input was provided, which part of the system failed and what the underlying error was. This level of detail needs to be planned into the application's design, not bolted on afterwards.

Retention and access

Log volume grows quickly. A moderately busy internal tool might generate gigabytes of logs per week; a customer-facing SaaS product can generate that per hour. You need a clear retention policy that balances operational needs, storage costs and any regulatory requirements. The UK GDPR framework, for instance, may influence how long logs containing personal data are kept.

Logs also need to be searchable. Storing them is not enough; the operations team must be able to filter by time range, user, error type or request ID. This typically means sending logs to a centralised log management service rather than leaving them on individual servers, where they become inaccessible if that server is replaced or fails.

Security and privacy considerations around logs — particularly what personal data they contain and who can access them — should be reviewed with a specialist, as requirements change and depend on your specific processing activities.

Error Tracking and Reporting

Error tracking is the practice of automatically capturing, grouping and presenting application errors so that they can be prioritised and fixed. It is distinct from log management: where logs provide a broad chronological record, error tracking focuses specifically on exceptions and failures.

Why grouping matters

If the same bug affects five hundred users, you do not want five hundred separate error reports. Error tracking tools group identical or similar errors together, typically by matching the stack trace — the sequence of code calls that led to the failure. This lets the team see that "NullReferenceException in DocumentGenerator.process()" has occurred 500 times in the last hour, rather than drowning in individual incidents.

Business context changes priority

Not all errors are equal. A broken image on a settings page is an error. A payment submission that fails silently is a far more serious error. Good error tracking allows you to annotate errors with business context and severity, so the development team fixes the issues that matter most first.

When reviewing error tracking with a supplier, check whether their setup captures the full stack trace, the user action that triggered the error, and the state of relevant data at the time. Without those elements, diagnosis becomes guesswork.

How to Choose Monitoring Tools for a Web Application

The monitoring tool market is crowded, and the right choice depends on your application's architecture, your team's capability and your budget over time, not just the initial price.

Selection criteria

• Compatibility with your stack — the tool must support the programming language, framework, database and hosting environment your application uses. Check the documentation, not just the marketing page.
• Integration with existing systems — can it send alerts to your team's communication channels? Does it connect to your incident management process?
• Learning curve — a powerful tool that nobody on your team knows how to use adds no value. Consider who will operate it day to day.
• Data residency — if your application handles UK personal data, understand where the monitoring tool processes and stores that data.
• Pricing model — many tools charge per host, per user or by data volume. Estimate your actual usage, not the entry-tier price, because costs can increase significantly as you instrument more of the application.

Questions to put to a supplier or implementation partner

• Which specific metrics will be visible from day one, and which require additional configuration?
• Who is responsible for maintaining the monitoring setup after launch?
• What happens to monitoring data if we change suppliers or bring the work in-house?
• Can you demonstrate the alerting configuration, including how false positives are minimised?

Avoid choosing a tool based solely on brand recognition or a feature list. The tool that is best for a large engineering team running a distributed microservices architecture may be entirely inappropriate for a small operations team managing a single monolithic application.

What to Monitor in a SaaS Application

SaaS applications have monitoring requirements that go beyond those of a single-tenant internal tool, because the provider is responsible for the experience of many separate customers on shared infrastructure.

Multi-tenant health

In a multi-tenant system, aggregate metrics can mask problems. If overall response times look acceptable but one tenant's data has grown to the point where their queries are consistently slow, the aggregate dashboard will not show it. You need the ability to examine metrics at the tenant level, or at minimum to identify which tenants are consuming disproportionate resources.

Subscription and billing processes

The commercial lifeblood of a SaaS product — subscription renewals, payment processing, plan upgrades and downgrades — should be monitored as carefully as the application itself. A failed payment batch or a broken webhook from your payment provider can have immediate revenue impact. These processes often run in the background and fail silently unless specifically instrumented.

Onboarding and activation flows

For SaaS founders, the onboarding process is critical. If the step where new users connect their first integration or import their data starts failing, new signups will churn before they see value. Monitoring completion rates through onboarding steps, not just whether the pages load, provides early warning of conversion problems.

API rate limiting and usage

If your SaaS product exposes an API, monitor how each tenant is using it. Unexpected spikes may indicate a bug in a client's integration, a misconfigured retry loop, or an attempt to extract data in bulk. Rate limiting should be in place, but monitoring actual usage patterns helps you detect problems before limits are hit.

How to Create an Incident Response Runbook

An incident response runbook is a documented set of instructions for handling specific types of failure. Its purpose is to ensure that when something goes wrong — particularly outside normal working hours or when the person who built the system is unavailable — the responding team has a clear, tested process to follow rather than improvising under pressure.

What a runbook should contain

For each foreseeable incident type, the runbook should cover:

• How to confirm the incident — what check to perform to verify that the alert is genuine and not a false positive.
• Initial diagnosis steps — where to look first in the monitoring dashboards, logs and error tracking to understand the scope and likely cause.
• Immediate mitigation actions — what can be done to reduce user impact while the root cause is investigated. This might include restarting a service, switching to a fallback integration or disabling a non-critical feature.
• Escalation path — who to contact if the initial steps do not resolve the issue, including out-of-hours contacts.
• Communication steps — how and when to inform affected users, internal stakeholders and any dependent teams.
• Resolution and post-incident review — what to document once the incident is resolved, and how to trigger a review to prevent recurrence.

Keeping runbooks current

A runbook that has not been updated since the application was first launched is likely to be misleading. Architecture changes, new integrations, infrastructure migrations and personnel changes all render old instructions inaccurate. Runbooks should be reviewed and tested as part of any significant release, and their accuracy should be verified during any post-incident review.

If you are working with a development supplier, clarify who owns the runbook, whether it is treated as a deliverable, and whether it is updated as part of ongoing support. A supplier who builds the system but does not document operational procedures is leaving a gap that will become apparent at 3 a.m. on a Saturday.