SQL Server Health Check or Slow Application Triage: which question are you trying to answer?

“We should have SQL Server checked” and “this report keeps timing out” are both useful starting points. They ask different questions, so they need different evidence and a different focus.

Start by deciding what your team needs to know next. Do you need a review of the main risks on an instance, or an investigation of one slow application operation?

Choose a Health Check for the main instance risks

SQL Server Health Check is a fixed-scope review of one SQL Server instance, one host context and up to five named user databases. It considers configuration, maintenance, backup/recovery metadata, integrity-check history and available performance indicators.

It includes one workload sample of up to 60 minutes and can identify up to five query candidates for later investigation. The purpose is to give your team an evidence-backed risk profile and prioritised action plan. Identifying a query candidate is different from carrying out a detailed tuning investigation of that query.

A Health Check is a useful starting point when your question sounds like:

• “We inherited this instance and want to understand its main risks.”
• “We need to know what to address first.”
• “We want a review of configuration, maintenance and backup coverage.”
• “We do not have a dedicated DBA and want a clear set of priorities.”

It is not a full estate audit, a restore test or a detailed investigation of every slow query. A sound configuration or no material issue can be a valid finding; the assessment does not promise a performance improvement.

Choose Triage for one slow operation

Slow Application Triage focuses on one SQL Server instance, one application, one named user database and one symptom. The symptom might be a screen, report or transaction taking too long or timing out.

The scope includes one representative capture window of up to 60 minutes, up to seven days of available performance history and up to five relevant SQL statements or plans. The review connects the operation with the SQL evidence that can be observed. It may identify likely contributing factors, or explain what further application, infrastructure or workload information is needed.

Triage fits questions such as:

• “This report is slower than it used to be. What should we investigate?”
• “One screen times out at certain times of day.”
• “We need to understand whether the captured SQL activity explains the delay.”

Microsoft’s application troubleshooting guidance considers the application, operating system, network and SQL Server rather than assuming every application delay has a database cause. That is why the affected operation and its timing matter. Read Microsoft’s whole-application performance guidance.

Compare the question and the evidence

These are starting points, not an automatic booking decision. The service pages contain the full limits and prerequisites. A wider environment or more than one symptom may need a separately agreed scope.

Prepare a useful description before choosing a collection mode

For a Health Check, identify the instance and named databases you want reviewed, why you are asking now and any concerns your team has already noticed.

For Triage, identify the operation, typical and slow timings, frequency, user impact, recent changes and timestamps with a timezone. Agree a safe way to reproduce the issue and identify someone who can use the application during the collection window. Do not repeat a transaction that changes business records without an agreed safe approach.

Historical information can help with an intermittent symptom, but it may be unavailable or may not cover the event. Query Store’s usefulness depends on support, configuration and captured history. A missing history source is a limitation to discuss, rather than a reason to silently turn on persistent collection. Microsoft’s Query Store overview explains the feature.

Choose who will collect the evidence

With Self-Service, your team runs the agreed BriteThought Diagnostic Collector and submits the results; BriteThought analyses the accepted evidence. Customer-specific permissions, network, security and execution troubleshooting are outside Self-Service. Your team needs to be comfortable arranging the approved collection.

With Managed, your team arranges appropriate approved access and BriteThought collects the evidence and carries out the assessment. Access restrictions can still limit collection. Review the chosen service’s allowances and prerequisites before deciding.

Start with a brief enquiry. We confirm the fit, collection method and handling arrangements before you share diagnostic packages or credentials through an approved process. The website does not accept diagnostic uploads.

Use the findings to choose the next step

Both services deliver a written result for the agreed question. A diagnosis, no material issue or a documented inconclusive result can complete the work once enough evidence has been accepted for analysis. An inconclusive result should explain the uncertainty and next useful test. Failure to collect enough evidence before analysis is a different situation, governed by the collection, upgrade and refund rules.

Recommendations are not permission to change production. Testing, implementation, broader investigation and ongoing administration need their own scope and approval. The full service pages explain timing, Priority availability, completion and other terms; this comparison does not replace them.

If you want the main instance risks reviewed, assess your SQL Server health. If you have one specific slow operation, investigate the slow operation. If the question is still taking shape, use the service finder to compare the published options.