The admin console view for recent signups took roughly 25 seconds to render a list of about 15 rows in the observed environment. Support staff used it as a daily starting point, so the latency was clearly unacceptable for the task.

I opened the ticket expecting a layout fix. The title said responsive design and the file it pointed at was the admin console template. When I loaded a profiler trace to understand what was actually executing, the first thing I saw was the new signups section resolving through a FULL OUTER JOIN against the session log table.

the query was answering the wrong question

The session log table recorded high-volume activity over time. For the specific recent-signups screen, the trace showed that the join was doing more work than the view required. The customer table already held the relevant signup-date field, making it the more direct source for this display once the team verified the business definition of a recent signup.

Above the new accounts list, the summary widget had a different problem. It was running unbounded COUNT(*) queries to populate tooltip labels on hover. No date range, no scope, nothing limiting the count to a recent window. Every admin console page load, the widget would ask the database to count the full contents of several tables and embed those numbers in labels that appear when a user hovers and disappear when they move away. The count was never wrong. It just had no business being recalculated on every page load to power a tooltip.

This is a form of feature debt that can accumulate as data volume and usage change. A count that was acceptable at an earlier scale may no longer justify its cost, especially when the value appears only in a low-priority UI detail. The connection between a hover label and page latency is easy to miss without measurement.

what the fix actually required

The new signups rewrite stopped using the session log table as the source and pulled directly from the customers table with a filter on the signup-date column. The admin console does not need session history to show who signed up recently. It just needs to know when they signed up. After the rewrite, the observed view time dropped from roughly 25 seconds to about 500 milliseconds on the same test data. That result was specific to the measured environment and query shape, not a benchmark for every implementation.

The fix for the summary widget was to stop computing the count on demand. Whether you cache it or remove it from the tooltip entirely depends on whether the tooltip is worth keeping, and in this case the answer was no. Neither the table structures nor the server were the problem. The queries were doing more than the screens required, and nobody had traced the latency to the SQL causing it.

The production app is an ASP Classic SaaS I inherited when I bought the business. The admin console has accumulated queries that made sense on smaller tables and have quietly gotten slower since. Finding them requires actually running the queries and measuring them, not reading the code and guessing. A slow page is the signal. The profiler trace is the map.

giving diagnostics the right evidence

An AI assistant can be more useful when it can inspect the same safely scoped evidence as the reviewer. That does not justify sharing a personal administrator login, persisting a privileged session cookie, or granting broad production access.

For a sensitive admin workflow, use a dedicated least-privilege account, a sanitized staging environment, scoped read-only access where possible, short-lived credentials, and audit logging. If those controls are not available, provide carefully redacted traces, screenshots, query plans, and representative test data rather than bypassing access boundaries for convenience.

AI assistance can accelerate inspection and rewrite work, but it cannot replace the evidence that identifies the expensive operation. Without the trace and plan, a suggested layout fix would have addressed the ticket description rather than the measured latency. The important input was the profiler evidence, interpreted in the context of the screen’s actual need.

I did not audit the rest of the admin console during this ticket. Several other paths run similar aggregates on tables that have grown past the point where those aggregates are cheap. I do not have numbers for all of them. What I know is that the specific COUNT(*) in the summary widget was running on every page load, for every admin console user, against unscoped table counts, to power a tooltip.

A slow internal page may involve query shape, indexing, data volume, application work, network behavior, or several factors together. In this incident, the trace showed queries answering a broader question than the screen required. Measure before trusting the ticket or choosing a fix.