“The CRM feels slower than it used to be” is one of the least actionable sentences in operations. Slower than when? By how much? For whom? Without a record of what normal looks like, every performance conversation becomes an argument between memories. A baseline replaces that argument with a graph.

This is a guide to building one without a large tooling budget, and to turning it into alerts that people will not learn to ignore.

What a Baseline Is

A baseline is a recorded description of how the system behaves when it is healthy, across the usual rhythms of the business: the Monday-morning rush, the end-of-month reporting push, the quiet hours overnight. It is not a single number. It is a range, by time of day and day of week, for a short list of measures that matter.

The point is comparison. Once you have it, a new release, a new integration or a data growth spurt can be judged against a known reference instead of a feeling.

Choose Metrics at Three Levels

Resist collecting everything. A few well-chosen measures at three levels cover most needs.

What users experience. Page or screen load time for a few key actions, such as opening a contact, saving a record and running a common search. These are the numbers the business actually cares about. A simple scripted check that performs the action every few minutes from a representative location gives you a steady series, and it also tells you when the CRM is unreachable.

What the application is doing. Request rates, error rates, response times at percentiles rather than just averages, queue depths for background jobs, and session counts. Averages hide pain; a handful of very slow requests can leave the average looking fine while a user waits half a minute. Track the slow tail.

What the infrastructure is doing. CPU, memory, disk space and disk latency, network throughput, and database figures such as connection counts, slow query counts and lock waits. These explain the “why” when the upper levels change.

The relationship between the levels is what makes diagnosis fast. If user-facing time rises while CPU stays flat, you look elsewhere than computing capacity.

Capture It Properly

Collect for long enough to see the full cycle. For most businesses that means at least a few typical weeks, including a month-end if reporting is heavy. Record the conditions too: how many active users, which integrations ran, what release was deployed. A baseline without context is hard to interpret later.

Store the data somewhere that outlasts the server it describes. Keep enough history to compare against the same period last quarter or last year, since many CRM workloads are seasonal.

Write down the summary in plain language and keep it with your runbooks. For example: “Opening a contact is typically fast, with the slow tail rising briefly during the morning import.” The numbers belong in the monitoring tool, and the meaning belongs in a document someone will read at two in the morning.

Turn It into Alerts That Mean Something

Alert fatigue is the enemy. If the pager goes off for every blip, people mute it, and then miss the real event. A few principles help:

• Alert on symptoms users feel, such as sustained slow response or elevated errors, rather than on every resource threshold.
• Use sustained conditions, such as “above this level for ten minutes,” rather than single readings.
• Compare against the baseline for the time of day, since a busy Monday morning would otherwise trigger alerts that are perfectly normal.
• Separate urgent alerts that wake someone from informational ones that go to a channel for review.
• Give every alert an owner and a first action, so whoever receives it knows what to look at.

Disk space and certificate expiry are worth alerting on well in advance, because they fail in a predictable direction and cost little to catch early.

Metrics at a Glance

Level	Example measure	What a change suggests	Alert style
User experience	Time to open a record	Something affecting everyone	Urgent if sustained
User experience	Synthetic login success	Outage or authentication problem	Urgent
Application	Error rate	Bug, dependency failure or overload	Urgent if elevated
Application	Background job queue depth	Jobs not keeping up	Review, urgent if growing
Database	Slow query count	Missing index or growing data	Review
Infrastructure	Disk space trend	Future outage	Early warning
Infrastructure	Memory pressure	Leak or undersizing	Review

A Hypothetical Example

Suppose a team notices complaints that the CRM is “slow on Tuesdays.” Without data, the discussion goes in circles. With a baseline in place, they overlay the last few Tuesdays against the typical week. User-facing response time rises sharply around the same hour each week, application error rates stay flat, and database lock waits climb at exactly that moment.

Checking the schedule shows that a weekly reporting export begins then. The export was added months ago when data was much smaller. The team moves it to an off-peak slot and splits it into smaller batches, then watches the same graphs to confirm the Tuesday bump has flattened. The baseline did not solve the problem, but it turned a vague complaint into a fifteen-minute investigation and gave them a way to prove the fix worked.

Keep It Current

Baselines age. After a major release, a hosting change, or a large increase in users or data, record a fresh one and note the date. Treat deviations that persist as information rather than noise: if the new normal is slower, either accept it knowingly or find the cause.

Finally, use the baseline for planning. A steady upward trend in storage or database size lets you request budget or capacity before it becomes an emergency. Planning ahead depends on seeing the slope, and the baseline provides it.

Frequently Asked Questions

How long should we collect data before trusting a baseline? Long enough to cover your normal cycles, which for many organisations means several typical weeks including a month-end. Seasonal businesses may need to compare against the same period in previous years.

Which single metric is most useful? If forced to choose, a synthetic check that performs a key user action and records how long it takes. It reflects the user’s experience and catches outages.

Do we need an expensive monitoring platform? Not necessarily. Many open-source and built-in tools cover the basics. Choose what your team will actually maintain, and check current documentation for what your hosting or CRM platform already provides.

Why use percentiles instead of averages? Averages hide the slowest requests, which are often the ones users complain about. Percentiles show how bad the slow tail is, which gives a truer picture of experience.

How do we avoid alert fatigue? Alert on user-visible symptoms, require conditions to persist, compare against time-of-day norms, and review noisy alerts regularly, deleting or tuning those that never lead to action.

Next Step

Pick three user actions that matter most, such as opening a contact, saving a record and running a search, and set up a scripted check that times each one every few minutes. A week of that data is the start of your baseline.