Four minutes to post: why a baseline beats a memory

Somebody says the posting run takes four minutes now. Was it two minutes last year, or three and a half? Nobody knows, because nobody wrote it down. So the conversation that follows is about memory and mood: the finance team is sure it got worse, the partner is sure nothing changed, and the only thing both sides agree on is that it is annoying.

A number nobody recorded is a number nobody can defend. Without a baseline you cannot tell a regression from a perception, you cannot show that a fix worked, and you cannot tell the business whether this month-end will be like the last one.

What a baseline actually is

A baseline is not a dashboard. It is a short, dated list of the operations the business feels, how long each one took, under what conditions, measured the same way each time. In our practice three to five operations are enough to start:

• The posting run that people wait on: sales, purchase or journal posting, whichever finance complains about.
• The month-end or period close, end to end, with the steps that take longest named.
• The report or page that somebody opens every morning and watches load.
• One integration that the business depends on, timed from the moment it is sent to the moment its result is visible.

For each one, record the date, the duration, the data volume where it matters (how many lines were posted, how many documents were in the batch) and anything unusual about the day. Volume is the part people forget, and it is the part that explains most slow drift: the same operation over twice the rows is not a regression.

Let the platform keep the record

A stopwatch works for the first baseline. After that, use what the platform already records so the number is continuous rather than a single sample:

• Business Central telemetry records long-running SQL statements with their execution time and the AL object that issued them, and long-running AL methods with their execution time. Saved as a query, the same filter run monthly becomes a trend.
• SQL Server Query Store keeps runtime statistics for queries in time windows, so you can compare this month's duration for the same query with last month's, and see whether a plan change lines up with the moment it got worse.

Neither replaces the business measurement. Telemetry tells you which statements were slow; it does not tell you the posting run took four minutes from the user's click to the confirmation. Keep both: the business number to know whether it matters, the platform numbers to know why.

When the number moves

The baseline earns its keep the day a number gets worse. In our practice the first question is always volume: did the operation slow down, or did it do more work? Posting 900 lines in the time it used to take to post 400 is not a regression, and treating it as one sends people looking for a fault that is not there.

If the volume is the same, look for what changed on the date the number moved. A major or minor update, a new or updated extension, a new integration, a job rescheduled into the same window, a table that has quietly grown past a size its indexes were designed for. Query Store makes the database half of that question concrete: if the same query has a new plan from the same date, you have found the start of the story. If nothing changed and the number still moved, that is worth knowing too, because it points outside the application, at the infrastructure or the platform.

Either way, the conversation is now about a date, a number and a change, not about whether anyone is imagining it.

The traps

• Measuring once, after the complaint. A baseline taken during the bad week records the problem, not the normal. Take it in an ordinary week and repeat it.
• Measuring different things each time. "Posting" timed for ten lines in March and five hundred in June is two different operations.
• Keeping the number where only one person can find it. A baseline in someone's notebook leaves when they do.

Five checks for this week

• Ask finance and operations which three operations they wait on. Write down their answer in their words.
• Time each one in an ordinary week, with the data volume, and put the result somewhere shared with today's date.
• Save the telemetry query that shows long-running SQL and AL for those operations, so next month's run takes a minute.
• Check that Query Store is on for the Business Central database and retains enough history to compare a month with the previous one.
• Put a recurring reminder to repeat the measurement after every major update and every significant change.

Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.