In today’s world, this might mean something different, but in 2010, we had this value:
In our context, this was about being open and transparent. This is the text from the facing page:
No gossiping, no intrigue, no pussy-footing around problems and no telling people what you think they want to hear whist privately disagreeing. We will be transparent in our dealings.
In a small company (2010 must have been 200-ish people), this made a lot of sense and I think overall we minimized politics. I don’t know this will ever be a “no politics” world for Redgate or any other, but we were better about publicly disagreeing.
I think we’ve lost a little of this over the years, as I see more people talking a bit inconsistently to smaller, private groups than they do to large ones. I try hard not to do this, though I’m sure my open-ness sometimes rubs people the wrong way.
I’m OK with some conflict. I’m also OK debating and disagreeing about what we do or why/how we do things. I think it’s healthy to do so.
I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.
I wrote a blog about sitting at LHR recently and watching planes take off. That’s been a fun thing for me to do when I’m stuck at the airport. I can see a plane roll down the runway every 35-45s during busy times. This time I was sitting by a window in the hotel, working and watching.
There was a moment when I realized no planes were taking off. I looked and saw a vehicle rolling down the runway, and then realized there were two, one from each direction. It was an runway FOD inspection, looking for anything that might damage a plane.
It’s a little thing that has to be done regularly at an airport.
How many of you do little things in your job? Do you clean up old logs/backups/ETL source files? Do you double-check security for old/expired accounts, unused databases, forgotten audits/traces, etc.? Maybe do you check the status of patches across your database estate? Is there something else you should do semi-regularly?
I’ve seen many people (including myself) lose track of things over time because there are so many. My phone (or pager) has rung so many times because a system ran out of disk space due to old files that accumulated over time. Those log files might not be be large, but after years the size can add up. And they’ll fill up a disk at night, not during working hours.
This is where AI might help. I’ve written many little scripts that helped me clean things, but they were often brittle and focused on a specific task. Generalizing them would take too much effort, and might not even be possible. After all, sometimes I’m not even sure what the general case would be when building the utility.
AI coding agents can help us in this space. Ask an AI for a script to remove old backup files, leaving the last few. Perhaps you want to look for unused accounts. You can ask an AI to setup an audit to scan for login times (script one) and then process the results to get the last login time for each account (script two). The action might be to disable accounts that haven’t logged in for six months (script three). Set these scripts to run ad hoc or on a schedule as needed. Just be sure you have a calendar entry to remind you to check the results.
Each of these scripts isn’t that complex, but across many systems, perhaps with slightly different requirements and situations, you might not have time to adjust each script or even build them. However, if you can think about a small utility, an AI can help you build it. Just be sure you also ask the AI to set up tests to ensure the script works as intended. This is especially important since you’ll likely be asking the AI to refactor or change the code and want to prevent regression bugs.
Doing the little things at work can eat up a lot of time, but building small utilities can help you can ensure that your systems run smoothly. And ensure you still get home in time for dinner.
We’re coming back to New York, which is exciting for me. I love NYC.
The Redgate Summit 2026 – New York City comes back on May 5, 2026. You can register today and I’ll see you back in Manhattan the first week of May. Once again Bob Ward is giving the closing keynote, with me and fellow Redgater’s giving the opening one.
We’ll have three tracks, but I’ll be hosting a session with one of our customers, so you can hear how and why Redgate Monitor helps them out and what it’s like to work with Redgate. We did this in Chicago, and there were some great questions from the audience.
We’ve chosen customers who have had good experiences, but feel free to ask them anything about how Redgate Monitor works and how we are as a vendor. I’m certainly proud of how we partner with customers, so come get a first-hand view from a large financial services organization.
New York City is such an amazing place, and we’ll have a drinks reception after, but there is lots to do. I’ll be bringing my wife and we’ll likely go see a Broadway or comedy show the night before. You should do the same.
We also have a Redgate track and an AI one, so this is a great chance to see how Redgate views the world and how we’re approaching building software that helps you become more efficient inside your organization.
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.
Voice of the DBA 