- Hosts: Steve Stedman / Mitchell Glasscock / George Stedman / Shannon Lindsay
- Recording Date: May 7, 2026
- Listen on Spotify!
- Download Database Health Monitor
The Making of Database Health Monitor Stedman SQL Podcast Sn 3 Ep 11
Steve Stedman and his team discuss the evolution of Database Health Monitor from its inception in 2011 to its current state. Initially developed using SSRS reports, DHM transitioned to a standalone desktop application by 2014. Key features include the SQL Performance Viewer, Job History Report, Disk I/O Over Time Report, and Schema Search. In 2025, DHM version 3 introduced licensing, the DB Analyzer, and new reports. Pricing starts at $10/month for single server monitoring, making it affordable compared to competitors. The team emphasizes user feedback in shaping future developments.
Podcast Transcript
Steve Stedman 00:16
Hey everyone, and welcome to this week’s episode of the Stedman SQL podcast. Joining me today is Shannon Lindsay, George Stedman, and Mitchell Glascock. I’m Steve Stedman. I’m the host, and today we’re going to be talking about Database Health Monitor. Now it’s July, and July is Database Health Monitor Month at Stedman Solutions, so every July we kind of take a month to promote and celebrate a few things around Database Health Monitor. So today we’re going to go through a bit of the history there. All right, before we jump into the history, though, here’s a word from our sponsor:
Is your SQL Server slowing down your business? Slow queries, bottlenecks, and unexpected issues eating up your time. Introducing Database Health Monitor, the powerful tool built by our team at Stedman Solutions. Get real-time insights into performance with over 100 built-in reports, index analysis, weight stats tracking, and proactive alerts. Quickly diagnose and find problems before they impact your operations with an easy to use interface for DBAs and developers, monitor unlimited servers, tune queries, and keep your databases running healthy and fast. Download a free trial today at DatabaseHealth.com and take control of your SQL Server performance, all right. Well, on to the history of Database Health Monitor.
So, we often get asked about where this started or what we did to build this, and Database Health Monitor is one of those things that we bring into every client engagement to help with what we’re doing there to save time and to make it so our clients don’t have to go and buy another product for us to use in order to help track their databases, but where it started in 2011 I was working as a consultant at a company, and one of the guys I worked with, we’ll just call him Wayne, because that was his name, and Wayne is all into SSRS at this point in time, and SSRS came out in 2008 so it was still, I think, fairly new, but I had this pile of queries, we’ll call it a bag of queries that I would bring in that when I was working on analyzing a SQL Server. My process would be when a load test was run, or when things were having problems. I’d open up a set of queries, I’d have to find the right SQL file, open it up, run it, and then show however glamorous it was in SQL Server Management Studio at that point in time, which, by the way, Management Studio has evolved a lot since then, but Wayne says to me, he says, “You know, all these queries you’re running to show what’s going on with the SQL Server would be really interesting if you put them into SSRS and took a took advantage of some of the things in SSRS as far as displaying queries. So I started working on that in 2011 and by 2012 I was presenting at SQL Saturday in Vancouver, BC, a on what we had built, what I had built to start with. So let me just show some slides. This is my slide deck from 2012 and I think it was March something, middle of March in 2012 and I hadn’t even called the Database Health Monitor at this point. It was just using SSRS reports to analyze SQL Server Health. And anyway, so I talked about it at that point as a project that I started last year. Well, that was 2011 It started out as two reports, and it’s grown to a series of 10 reports, and I plan to add five more reports into the project over the next several months. Well, that didn’t quite happen that way, because I quickly outgrew what I felt comfortable doing in SSRS. But this is what the first version of Database Health Monitor looked like. It was a SSRS report that you would open and view through a browser or your SSRS development environment, and it had about 10 report links across the top. You’d put in the server you’re accessing, you’d choose the report, you’d click a button, and then you’d have to go view that report.
Steve Stedman 04:38
You click on each one of the different reports, there, pick what database you’re using with a drop down, and oh, it was exciting, the stuff we could do with SSRS back then, and there were some things that were kind of cool, like they had some cool visualizations on some of the data, but and this was the original overview panel. For the server overview, which we now have in Database Health Monitor, which is a whole lot different than this, and we had things like one time use queries, which that report is still in Database Health Monitor, although it’s using different components to display it today, and other things like backup sets. How big are our backups? Well, we have a report very similar to, well, yeah, very similar to this, but it’s more of a grid rather than a chart. We also have charts in this day. This is the one that we have backup growth over time. We have a very similar report to this too, as well, but it’s, I think, it’s a lot better because we include things like full diff and logs, and then some CPU charts, CPU load over time. I mean, this was all just being accessed through SQL Server SSRS reports, and so my plan at this point, when I debuted it at Vancouver SQL Saturday in 2012 was that I was going to expand this, I was going to make it easy for everyone to download these SSRS reports and use them to track and monitor their SQL server. Well, it didn’t quite work that way, because I did the demo, I made it all available, few people downloaded, and then they were having trouble getting it to work. Oh, I want to use this, but I don’t have SSRS, or my administrator won’t let me download third-party reports into SSRS or things like that, so that’s where, and we’ll just hit remove here, and that’s where I threw out the SSRS reports after what I considered that initial beta release, and through 2012 late 2012 through 2014 and on, that’s where I converted it over to a Win Form standalone desktop application, and then from 2014 through 2022 I just continued to add features and grow it as a standalone application. It was free, completely free as a beta.
And then in 2021 we added online classes, and that was the first time we started charging for it. And then in 2022 that’s where there’s a lot of people starting to use it, and we realized that we needed to make some money off this in order to be able to support it, because we spent a whole lot of time on it, and we added paid licensing and gamification, where you could do a bunch of things, different things, like a blog post, or join the mailing list, and you get free points to access the system, but then that evolved, and 2023 and 2024 I guess 2023 we continue to add new features, and two developers were added to the project. Welcome, Mitchell. Welcome, George. Now, technically, George had worked on this a little bit earlier. When he was in college, I had to give him a couple of tasks where he was going to go work and do some things in Database Health Monitoring. Added a couple features back prior to 2020 I guess it was. I don’t remember the exact dates on that, George,
George Stedman 07:52
you know that would have been 2019 or 2020
Steve Stedman 07:57
Yeah, anyway, so that brings us to kind of 2020 2022 and on, where we started adding quite a few features, and with three people working on it, rather than just me, there was a whole lot more going on in the product at that point. So, Mitch, you want to talk a little bit about some of the things that we started adding? Then, yeah, I mean, I joined in 2024 as a what started as an internship, and that introduced me to the development side of Database Health Monitor, and from the beginning, and this is kind of framed as what you’ve done since you started development in 2011 is from the beginning.
Mitchell Glasscock 08:30
It’s what, what is the problem that we run into with clients or in different areas with SQL Server, and how can we make that easier to surface with Database Health Monitor? So, whether it was one of the team members saying, hey, it would be really handy to have this solution in Database Health Monitor, or something that I ran into personally, and I was like, this would be great to have Database Health Monitor, that’s been the framework for building this program and evolving its future.
Steve Stedman 09:15
Yeah, some good points. So, a couple more things I’d like to add on that too, is that I mean, the thing I didn’t cover in here was in 2015 was when I started Stedman Solutions, and then Derrick was the first team member that came on at that point, and Derrick and I were doing a whole lot of consulting hours and projects for people back then, and every time there was something that was painful or difficult to do, Derrick would bring it to me, and we’d figure out, well, how can we add that into Database Health Monitor to catch it, or to make it faster, or to prevent it from happening again, and all those kind of things, and a lot of the features evolved out of that, and then Mitchell and George, you both got involved, and yeah, every time we work with clients, like you said, and we find something that’s we want to add or catch. It’s usually from some experience we’re having with that client, right?
Mitchell Glasscock 10:02
Yeah, I think one of the first things that we talked about was the health summary that you started building in the SSRS reports, and that’s evolved. We still use that in function today in the quick scan report in Database Health Monitor, and that was one of the first projects that I ever started taking part in was building new quick scan report checks, looking back at our release notes back in 2024.
Steve Stedman 10:31
Yeah, we’ve got well over 200 different checks in the quick scan report now.
George Stedman 10:35
Yeah, and I would say, like when we first came on as developers, it was kind of, I would say, our it was kind of slow as we were getting used to the how you had coded it and all that, and we really took off when we started when you started putting us on the managed service clients, and we started experiencing all the problems ourselves, and we could actually, like, we had had experience developing in Database Health Monitor, but we had no real, like, practical knowledge on any of that stuff, I think we had a little bit from college, but like seeing the stuff firsthand and being like, oh well, instead of trying to find a query to go do this, we just, we could just add it as a button, just add it as an instance report, and then it’s just instant results in front of a client, which is just priceless.
Mitchell Glasscock 11:20
I think there’s a big difference in, like, when I first started, Steve, it was like, hey, I really want to do this, and it made sense conceptually, like, let’s take, like, high VLS as an example, it made sense conceptually as far as why having too many VLFs is not a good thing, and why we should report on that in the quick scan, but it wasn’t until I ran into it, and I saw it on a client’s computer, where I was like, “Oh, there’s like 500 VLS here, and I need to restore this, even just a test restore, it took five times, five or 10 times as long to restore that file to a new database or to a new server, so like George said, getting on the managed service side and getting exposure to real world problems makes the development mean so much more on our side.
Steve Stedman 12:19
Yeah, and what’s interesting on that as well, Mitch. I mean, I’ve been dealing with VLFs for 20 years now, and trying to fix them and straighten them out for clients over the years, and it was always some custom script that I ran to fix it, and I know that was one of the projects you worked on. I assigned it to you, and maybe you hadn’t had the experience in actually dealing with it there, but yeah, now that you’ve been thrown in to the managed service clients, you do, and it helps a lot. So, even, even though I was getting a lot of value out of that report when you did it before you, you joined in on the managed service clients, it was, it was good stuff.
Mitchell Glasscock 12:53
I think all that to say, it’s not, it’s not like these reports are just pulled out of thin air, it’s, it’s these reports are generated because of real world problems things that we need to fix, and so if you have a SQL server, there’s a good chance you’re going to run across these, these issues.
Shannon Lindsay 13:13
Now that everybody’s kind of been working on it for, I guess, we’re coming up on like two, two and a half years. What do you think is probably each of your favorite things you’ve added or noticed added to Database Health Monitor?
Mitchell Glasscock 13:29
mean, I don’t mind if, if anyone else wants to go first, but
George Stedman 13:33
go for it.
Mitchell Glasscock 13:34
The job history report.. I don’t remember the exact situation that came up, but we wanted to visualize a really easy way to see how long jobs were stacking up against each other, how long they were taking to run, and it took me a month of tweaking here and there, and then we finally deployed it, and we, we used it to schedule a bunch of maintenance periods, because a client was running, they were, they were running some overnight processes that were business-like, they were required for business, but they were also needing to run their maintenance stuff overnight as well to reduce impact during daytime operations, and to see that some of the maintenance and some of the business process were overlapping and causing a massive slowdown at a certain time period, and just being able to adjust it based on the visuals was a huge, huge help compared to trying to dig through the SQL Server agent and the job history there to see and compare numbers instead of visualization,
Steve Stedman 14:42
and you know it’s interesting, because with that report it’s always a challenge to figure out where you’re going to put that check DB or when are you going to run those backups, and that report just gives a great way to visualize it and be able to see the holes in the pattern and figure out where to drop those things in.
Mitchell Glasscock 14:57
Yeah, and the other thing is it’s such a mind. Our feature, but a lot of those maintenance tasks can be really CPU heavy, and just hammer it so the top bar shows your CPU usage, so you’re not, you can see if you’re going to schedule it during an already CPU heavy time, so you can free up resources looking at it.
Steve Stedman 15:16
Yeah, and that was an interesting one, because that little CPU chart in there that shows what the CPU load is when those are going on, that wasn’t there in the initial plan, but as we started using it, we realized it’d be really nice to have that, and then next thing you know, it was in there.
Mitchell Glasscock 15:30
yeah, I think it was like a day of flipping back and forth between our CPU charts and the job history charts, and we’re like, what if we just put them together?
Steve Stedman 15:36
Awesome. All right, George, what’s your favorite feature?
George Stedman 15:39
I mean, I think it was one that Derrick had requested. It was one of those, like, we can see the well, I guess I should just say the feature right away. It’s the disk IO overtime report. It was one where Derrick, I think, was working with a client, and he noticed the IO was really heavy when, like, the he had noticed through, like, a couple other different queries, that the disk I/O was the biggest impact on the queries, but it’s not one of the things that’s necessarily as obvious as like CPU or memory, or yeah, CPU or memory, and it’s just one of those, like, you just assume your disks are good, you assume they’re fast enough, but we ran this report on a client right away, and it was like, I think it was like eight seconds of latency on the disks right away, and we’re like,
Steve Stedman 16:32
eight seconds, not eight, not eight milliseconds, 8000 milliseconds,
George Stedman 16:37
8000 milliseconds of latency on the disks, and we’re like, okay, and then we looked further into it, and think it was a really disc-heavy query, or we realized that they were just running really, really old drives.
Steve Stedman 16:52
Yeah, that’s a great one. And I don’t know how many different performance assessments that I’ve worked on since we added that, where we’ve been able to either confirm that they’ve got good IO, or to point out that they’ve got IO issues, and maybe IO issues on just your Temp TB drive, or IO issues on a specific drive, and to be able to fix those by moving things around or adding more disks, and being able to see the difference is just really, really cool. So, yeah, that’s a good one.
George Stedman 17:19
The really cool thing about that one, too, is if Temp TB is on its own disk, you can really like narrow down that you’re tempted, be heavy.
Mitchell Glasscock 17:26
You brought up Steve, the performance assessment, that’s a the disk latency is one that we immediately go to if we see that files, if drive files are all on the same drive, or sorry, if temp tb data and log files are all in the same drive. It’s a great way to show why that disk is getting hammered, and if they separate it out, it’s showing the night and day difference at 99% of the time. There’s a huge night and day difference when you move those files around to new drives, that it’s a, it shows how much value is brought when those changes.
Steve Stedman 18:05
Yeah. And with that, I mean it is the best practice to put your data files on a different drive than your log files that’s on a different drive than your temp DB, that’s also on a different drive, hopefully different server than your backup. And none of that should go on your C drive, of course. And I’ve seen a lot of people over the years that just tell people, well, you got to do this. Well, the difference is when we do that performance assessment, we can go in and look and say, well, yeah, maybe you’ve got them all on the same drive, but you’re not having performance issues, so we’re okay, for whatever reason, that may stay there, even though there’s some good reasons to put the log on a different drive, but we can also go in and show them that, yeah, you can see that the latency is just stupid on this drive, for lack of a better term on it, and that by moving things around you can fix it, and that is such a good feeling to be able to show people that, let them do it, and then be able to show how well it’s performing after the facts because of that change.
Shannon Lindsay 18:59
All right, Steve, what was your favorite feature?
Steve Stedman 19:01
So, I had two in mind, and I know I only get to answer one, so I’m going to go with the SQL performance viewer. So, early on with Database Health Monitor, when we were doing performance work, and specifically working with, like, a client that was doing load testing and things like that, I would have, like, four different versions of database or four different instances of Database Health Monitor running all with different charts open, I’d see the what is active chart, I’d see the blocking, I’d see like CPU and stuff like that, and it just got annoying to manage so many windows being open in order to track all that, so that’s when I built the program, our Performance Viewer program, which basically takes a number of those same reports and puts it into one program that you can run and watch all of those things at once while you’re doing load tests or while you’re assessing performance issues on the server, and then just recently in the last update we added a couple of new reports into that and refactored it a bit, so we’ve got things like. High CPU queries are showing up in it. Thank you, George, for adding that one. We’ve got things like what weights are being reported and be able to get reporting on blocking and all that kind of stuff. So that one is my favorite because it adds so much value when a client is saying we’re having performance issues right now, we can run that and look at it and help figure out exactly why those performance issues are happening.
Shannon Lindsay 20:24
All right, well, we covered favorite features. What came next after adding Mitch and George to the projects and kind of progressing the program?
Steve Stedman 20:36
Well, lot of new features. One of them that came out in 2025 was what we referred to as the Database Health Monitor version three release. This was a pretty big release, where I gosh, we must have gone six months or so without any major releases along the way there, and we bundled up a lot of new functionality in there. Now one of the new functionality items was licensing in the way that we handle the licensing, and we no longer do the free if you’re doing the gamification like we did in the past. Now you get a free, I think, two week trial, and then maybe it’s 30 days, I forget, and then after that it’s pay, but in doing that, we also added a lot of features, like we added the DB analyzer, which is a tool you just pointed at your database, and you hit analyze, and it goes out, and it finds things that need attention, and comes back, and tells you about them one by one, and offers solutions, and sometimes even offers to fix them for you. Other stuff that was added in there, I mean, a lot of new reports. George Mitch, what were the big version three things that you worked on?
George Stedman 21:45
I think the one I remember a lot of, I think Mitch polished up schema search a lot.
Mitchell Glasscock 21:50
Oh, yeah, yeah, that was one that Steve, Steve, and I took a lot of time to. It had been in beta for a while. It was another one of the side projects that Steve, you had started up, and the functionality was great, but we just hadn’t taken the time to sit down and kind of wrap it up and polish it, so we, we grinded that one out and included it, that’s included in every release as of right now with Database Health Monitor,
George Stedman 22:18
and that’s just an instance report button now.
Mitchell Glasscock 22:21
Well, we have the schema search, that’s a huge function that we added. The SchemaDrift is another side tool that we release with Database Health Monitor.
Steve Stedman 22:32
Yeah, so there’s two sides to that. One is the report, and Database Health Monitor lets you do a quick search, and I think I use that every single day, whenever I’ve used it twice a day already, and it’s only slightly afternoon.
George Stedman 22:43
Oh, it’s so helpful,
Steve Stedman 22:44
but yeah, but the other one was the SchemaDrift, which is where it’ll go and take the entire schema and allow you to compare it between two different databases and save it out to disk as well, and that, like Mitch said, that was one that I had thrown together like in 2017 or something like that, and then hadn’t really worked on it for about five or six years, then we came back and updated it, made it more modern, and yeah, it’s a core piece of what’s in Database Health Monitor today.
Mitchell Glasscock 23:11
Yeah, I mean, there’s a whole list of new instance reports that we added, the problem, the problem indexes, backup timeframe, CPU by query, those are just a few of the instance level reports that we’ve added. A lot of the reports got an overall tweaking just for performance as well inside of Database Health Monitor. We just spent it was between May and August of 2025 that we sat down and just overhauled a massive amount of Database Health Monitor for this version three release, so
Steve Stedman 23:45
with that, you saw some of the PowerPoint slides that I showed earlier on with the initial, I don’t know if I’d even call it beta, it was the initial prototype. Why don’t we take a quick look at some of how it looks today? So let’s run through that real quick.
Speaker 1 24:14
Coffee’s cold. Dashboard is red again. Spinning wheels, but the screen just grins. Every query takes a lifetime now. Database is stuck, but I’ll find out how..Hey, Database Health Monitor tell me what’s going wrong. Who’s holding up, what’s blocking? Why this query is so long. Show me every query plan, every block, every deadlock. Database Health Monitor, Keep my SQL server running smooth. Table scan, hiding in plan, implicit conversion, wrecking all my plans, locking chains, locking up the application, I check plans till it’s clear once more. Oh yeah, Database Health Monitor tell me what’s going wrong. Who’s holding up, what’s blocking? Why this query is so long. Show me every query plan, every block, every deadlock. Database Health Monitor, keep my SQL server running smooth, missing index slowing to a stand, dreaming of a seek happening all week. How many indexes is too many? We need one more till it’s clear once more. Oh yeah, Database Health Monitor tell me what’s going wrong. Who’s holding up, what’s blocking? Why this query is so long. Show me every query plan, every block, every deadlock. Database Health Monitor, keep my SQL server running smooth. Glassy ghost in the numbers, reports flash red, then a line, every block is a story, every table seek a warning sign. Database Health Monitor tell me what’s going wrong. Who’s holding up, what’s blocking? Why this query is so long. Show me every query plan, every block, every deadlock. Database Health Monitor, Keep my SQL server, Keep my SQL server, Keep my SQL server running smooth.
Steve Stedman 27:44
Wow. Well, that’s a catchy tune. I like that. So, comparing some of the screenshots we had there to what we saw in that original prototype, it’s come a long way over the last 15 years, and I think a lot of that has to do with the team we’ve got and the way we’ve grown it and added to it, and that really brings us into 2026 So, more, I mean, we’re not stopping now. We got more features going on this year. In fact, just recently we had a release of Database Health Monitor, which included a new plan viewer feature. This is really interesting.
So, gosh, it was maybe three months ago about that. Mitch, you and I were talking, and we were really diving into some plan analysis using the SQL Server plan viewer, and just kind of scrolling around as you do, scroll to the right, and then scroll down and looking for the percentages, and I think you said to me, should we create our own plan viewer or something that maybe makes this a little bit easier, and I don’t know, is that something like that, Mitch? And it was, it was the fact that we had to spend even just a couple minutes trying to scroll through each plan, trying to figure out where that higher percentage was, or where a warning was sitting, yeah, and my response at that time was no, we don’t want to do that, we don’t want to reinvent. I mean, SQL Server does a pretty good job with that, and I do not want to spend time to go and do that. Well, got a little bit further into things, and we eventually ended up adding our own plan viewer, and this is available now for anywhere that we capture plans, like the blocking query monitor, like the long running queries, like high CPU queries in the performance viewer, where if there was a plan available at the time, we track that information, we capture that plan, and you can go view it, not with the way SQL Server shows it, where you can have to drag around, but it analyzes all of it, and it comes back with reports that say here’s the one thing that’s taking all the CPU, and you just click on that, and it goes to tell you, well, why is that? I shouldn’t say it takes all CPU, it takes all the cost, and then you click on it and figure out, well, why is it taking all the cost. The plan, why is that taking 99% of the whole plan, and it analyzes it, and instead of saying implicit conversion, it’s going to tell you what’s the implicit conversion is happening on, and what that really means. If, if there’s an index seek going on versus a, or an index scan versus a seek, it’s going to tell you those kind of things. For missing indexes, it’s going to recommend that as well, but it analyzes it in a whole lot more depth than what you get in what SQL Server normally shows you on the plans.
Mitchell Glasscock 30:28
It’s a lot more digestible if you’re not spending every day, day in and day out, like reading query plans and figuring out what all the little doodads and doohickeys in the plan, truly mean it’s way easier to read from an overall level.
George Stedman 30:48
Yeah, and one of the big things that you brought up again with was the performance viewer, and it’s like if you’re not like a database expert, if you’re just like a sysadmin that got promoted to DBA, and you’re just happen to take care of the servers and you get this tool and you’re just like okay, well, it’s slow every day around 12, so let me pop up performance viewer, and then it’s like, oh, look, immediately you can go see the high CPU queries that are causing the slowness, and then just analyze them real quick, and be like, oh, I just need to go fix this query that probably wasn’t written correctly, or I need to go finish fix my table schema, because there’s implicit converts happening.
Steve Stedman 31:25
An example of that, that query that we use in there to go and display the high CPU. We were working with a client on our performance assessment, where they hit a point where the CPU was so high at certain points of the day that it would just knock their system out. I mean, it would lock things up and backlog it, so that nobody could get through and do anything. Well, we were able to find that, analyze the plan, and make it to the point that they are no longer CPU constrained in that system, because of that. Anyway, yeah, that’s definitely cool. Cool feature. So, what else we got going on in 2026?
Mitchell Glasscock 31:59
One of the projects that you brought in was the query loading ramp that one was a one of your brand child’s after we had done some what was it performance they were doing load testing on a server for a client so we were standing by with our performance monitor and we were like you know, instead of going through a complicated load testing tool, why don’t we just have one where you can put in a stored procedure or a simple query.
Steve Stedman 32:29
Anything we want to cover before we kind of go into the closing at this point?
Mitchell Glasscock 32:33
I mean, one of the ones that I wanted to circle back on is we have transitioned to Database Health Monitor as a paid licensing option, but we wanted to keep it extremely affordable compared to other SQL Server monitoring tools that currently exist. So, I mean, we can, we can talk about some of the July promotions for Database Health Monitor, but outside of July, Database Health Monitor, if you’re monitoring a single instance, is 10 bucks a month to run that.
Steve Stedman 33:08
Yeah, and that’s the interesting thing, too, with that is that we originally had a pricing model where it was like one price for 10 or less servers, and we thought that was a really good price, and people came along and said, well, I only have one server I want to monitor, and can I get it cheaper? So that’s where we put together that $10 a month for a single server monitoring package. If you buy that through the through our online class with it, and or is it what, $99 a year or something like that, if you pay the yearly on it, and there is no competitor out there doing anything like this that you could get anywhere near that. I mean, you’d be over $1,000 for monitoring a single SQL server with most of those, so, and even if you are monitoring more than one SQL server, 10 a month is still only $30 and up to 20 is $40 so it’s not like we’re stepping up in price in ginormous amounts, it’s, it’s a very affordable tool compared to your $1,000 a month options out there. The cost per instance actually goes down to less than $10 a month when you go for that 10 or 20 instances that you’re monitoring.
George Stedman 34:20
Yeah, the other thing is, we, we’ve cooked the, the monitoring alerts and stuff directly into, into SQL Server, like, you just use this database mail, which a lot of the other competitors that have alerting, they run it all through their own servers and stuff, and send you like a personalized email, but ours just uses your own database, so it doesn’t even have to leave your own, your, your, your system to send you alerts, which makes them faster and potentially more reliable.
Steve Stedman 34:53
Yep, absolutely. So, I think throughout this year we’re going to continue to add new features and. Continue to improve the system. We’ve got several clients we work with who regularly provide us feedback, and we’re probably doing a release about every month. And we appreciate the feedback. If you’re using the product and there’s something that’s maybe not quite right or not what you’re expecting, let us know. We want to know that, so we can help improve it.
Mitchell Glasscock 35:18
Yeah, it definitely has helped shape, I mean, 2026 In general, a lot of, a lot of the features have been shaped by user feedback from the community, so it’s it. We are listening to every email that comes in and super grateful for those that sent us that feedback.
Steve Stedman 35:36
Okay. Well, I guess then any anything else you want to hit before we wrap this up.
Mitchell Glasscock 35:41
Nothing from my side.
Steve Stedman 35:44
All right. Well, thanks everyone for listening and watching today. As usual, if you like this or want to see future updates from us, hit the like button and the bell icon if you’re watching on YouTube. And we appreciate you being here and listening to what we’re showing here next episode, we’re going to show the query loading ramp and how to be able to load test your SQL server with specific queries, so please come back for that next time. And thanks for watching. Have a great day. Bye. thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it, and if you want more information, more videos like this, click the subscribe button and hit the bell icon, so that you can get notified of future videos that we create.