Tag: Redgate Monitor

We have multiple teams (8) working on Redgate Monitor. Some work on the Standard Edition, a few on the Enterprise Edition, and others handling core work, like the Linux/PostgreSQL option.

We also have designers, and they regularly research how well the product works for customers, what is difficult, and they propose changes. One of them was recently release. We have a new analysis page in Redgate Monitor and this post looks at the changes.

Video walk-through of this post below.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

The New Experience

If you go to monitor.red-gate.com, you can see this at: https://monitor.red-gate.com/Analysis. This shows the new analysis graph, which is easier to see and takes up the entire screen.

If you haven’t used this, I’ve added metrics below this for certain servers. You can see in the legend that I’m looking at CPU time along with batch requests for both sides of my cluster. I can compare these to see if the number of batches is impacting CPU. A correlation I might use to research how a workload affects my system.

If I put my cursor over the graph, I can get info on the metric, the current time and the value/min/mean/max. These values are for the time period.

If I change my time period, I see the values change for the stats.

Below this, for the metrics, it’s a little cleaner as well. The interface hasn’t changed a lot, but it’s a little larger and spread out. I can see that I pick a metric for a cluster, and then for a machine. This is the same.

What has changed is the “add a metric” is now at the top on the side. If I click this, I get a new set of metrics to pick below this. Note the “same as above” for the cluster, which is very handy. I can also type in the box to search.

At the right, the explanation of the metrics and statistics are still on the far right.

This makes an interesting experience that works smoother to ensure that

The Classic Experience

If you don’t like this, there’s a link in the upper right to switch back.

Clicking this loses my metrics, but if I add them back, you can see the old view. It’s a little less appealing to me. The other thing I hated is that the “add a metric” is below the list shown below, which is annoying. I often scroll down to find it.

I also have statistics which only show one of the metrics (first one?) and not both. I’m also missing stats of the average.

Summary

This is a small change, but a nice one, IMHO. The ease with which the UX is designed can make a big difference to how users can interact with the data. This is a small one, but one that I really appreciated.

If you have feedback in general, please let us know as we value your opinions and comments on how we shape the future of Redgate Monitor.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Video Walk-through

Video of this post below.

At the recent Redgate Summit in Chicago, I demo’d (lightly) the ML based Alert thresholds in Redgate Monitor and decided to write a little about this.

Video of this post below.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

Noisy Alerts

When people used to setup Redgate Monitor in the 2015 timeframe (formerly SQL Monitor) they sometimes complained about the noisiness of the alerts. Just too many alerts were sent out.

I felt this way about other products I’d used in the past, and our dev teams worked hard with support to enhance the produce and tune our defaults to make them less noisy. Many customers appreciate this, though a new install can take a little tuning to customize to what is helpful and actionable vs what is noise for each customer.

A Better Way

As the AI-LLM rise started in 2024, we started to work on different ways to use this tech in Monitor. One of our first ideas was an ML based alert that didn’t work on a set level to trigger, but rather would look at historical data and adjust the threshold for alerts. In this way you would

We released this in v 14.0.37, so you need to be on that version or higher to use this. This is in a documentation page that describes how this work. Basically we take 14 days worth of history (the min required) and run that through a machine learning algorithm to decide what a predicted level should be. There is a pad added, and you can still set a min threshold and a duration.

If the value exceeds the predicted value + pad, an alert is sent out.

This is intended to reduce the amount of alerting from a system that might have a variable workload, but one that repeats and is predictable.

Enabling Alerts

This is available for the following alerts so far:

• Processor (CPU) utilization
• Server waits
• DTU utilization
• Query throughput

If you go into the configuration for any of these alerts, you wil see a “dynamic alert” toggle that can be enabled. You can see this below where is says “Use dynamic alert thresholds”.

When you do that, you can still set the levels, and as shown below (from the doc page), you get an idea of how the threshold works. The predicted values are shown as the line. If the line gets into the red areas, an alert is raised.

The time limit works as shown for sensitivity. The value would have to get into the blue area, so you can see a pad around the predicted value alerts are not raised.

That’s it. Set the alert and if there is 14 days worth of data, each machine gets its own custom alert levels.

Seeing the Expected Values

When an alert fires, the alert includes the predicted values as well as the values recorded. You can see below in this alert that CPU was expected to decay, but hadn’t, so an alert is fired where the green line is shown.

At the top of the alert, you can see that this was generated by an ML process.

Summary

This dynamic levels should reduce the amount of alerts you get from variable workloads, since the predictions are made based on each machine’s history. You can set some threshold and sensitivity over time, but the actual values used for alerts are predicted.

There is also a feedback place in the alert so that you can let us know if this is helpful or not. We use feedback from you to help better tune our the ML works.

If you have feedback in general, please let us know as we value your opinions and comments on how we shape the future of Redgate Monitor.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Video Walk-through

You can see me check this out in the video below.

AI is everywhere. It’s in the news, it’s being added to every product, management wants everyone to be more productive with AI.

Redgate Monitor isn’t immune from this wave. We have spent a lot of time over the last year trying to learn about AI tech, experiment with it, and find ways that it provides values to customers, not just becomes a marketing label.

The big area is query analysis, though this wasn’t the first area. I’ll discuss another area in a different post, but this one looks at AI assisted query analysis.

This feature is a part of Redgate Monitor Standard, which hopefully gives many of you confidence that we haven’t abandoned this edition for the Enterprise one. We still haves teams working on features for everyone in Redgate Monitor.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

Getting Help with Queries

If you find a problem area on your server and scroll down to look at queries, you can expend the query details with the arrow on the left. When you do this, you see something like this:

Lots of these details are familiar, but the AI sparkle and purple button is new. It says “Analyze Query” and what this does is send some query details and context to an AI LLM that Redgate runs in AWS for analysis.

When you click this, it takes a few seconds and then a response from the AI LLM comes back. You get a summary, which in this case tries to look at the query, infer some intent and then use details from the query to give a quick view of what this query is doing. You can see this in the image below.

Below this, we give a performance analysis. In this case, we get the state and some observations about how this query plan looks. In this case, we see estimates of cost and rows, parallelism, etc. and then that this is a system function, there are implicit conversions, and large rows.

The section below this has recommendations. These are guesses at things that might help improve performance. In this case, there aren’t a lot of items, but some of these can help, like the implicit conversions.

Here is another plan, in this case, there are three items noted from the query. There is some detail and ordering. The implicit conversions here are critical as these can dramatically slow the query. The second item, noting over 1 million rows, is another thing to look at and lastly, SELECT *.

Below this are positives and action items. You shouldn’t blindly follow these items, but rather evaluate and test if they make a difference. In this case, these would help.

We try to intelligently pass through context to the AI LLM, but we are not custom training LLMs. We are hosting the models, so no data is being saved. We send context, get a response, and then that session closes with none of your data kept. You can read more in our AI FAQ.

Note the upper right corner of the first image, where we tell you that this content might have mistakes and you should check. You can also click thumbs up/down and provide feedback if you wish.

Summary

This post looks at the AI query analysis, which is in preview as of Feb 2026. This is intended to help you more quickly analyze what’s happening on your servers. This should help your team have a consistent view of what is going on and help share knowledge among team members.

If you find issues, or value, in this feature, please send us feedback as we are looking to improve this feature over time.

If you have feedback, please let us know as we value your opinions and comments on how we shape the future of Redgate Monitor.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

One of the features we advocates have been advocating for is a better way to track security changes in your SQL Server instances. The first slice of this work is in preview (as of 12 Jan 2026) and this post looks at what’s available.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

Tracking Security Changes

The first iteration of tracking security changes queried instances and databases for information, stored it, and then compared it with other queries to determine what had changed. This was done hourly, and worked well, but it could not determine exactly when a change was made.

SQL Audit is made to capture this information in a lightweight way This works well, although the tooling (IMHO) is poor and hard to work with. Redgate Monitor is going to overlay this and make it easy for DBAs, InfoSec, and auditors to better understand what is happening in a SQL Server Environment.

There is a new tab in Redgate Monitor Enterprise Permissions page that contains this data. This is listed as “SQL Audit” and you can see this below.

Each row in here gives the time of the change, as detected by SQL Audit. If I expand the first column, I can see the details. In this case, we have a regular workload running to change these so that the demo site has data, hence you are likely to see the same data every day on monitor.red-gate.com.

The last column in the right has the command captured, with PII redacted, as you can see here. The reason you may see only the CREATE LOGIN items and not DROP LOGIN is this first slice of work is just getting the additions, so you can catch those hackers trying to add accounts.

The SQL Audit documentation page explains how this works, and keep checking this as there is a team enhancing these features on a regular basis and adding more events.

As with most of the pages in Redgate Monitor, you can filter and customize what data is displayed. You can also export your data as an csv file you can give to others. You have the option to get all data or just filtered data.

Summary

This post shows how a new preview feature in Redgate Monitor Enterprise uses SQL Audit to gather data on specific actions that are being taken on your SQL Server instances. This is a useful feature many customers have requested and it is being actively enhanced, so feedback is appreciated.

If you have feedback, please let us know as we value your opinions and comments on how we shape the future of Redgate Monitor.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.