Documentation
Learn how to set up and get the most out of MIIDBA for your SQL Server monitoring.
What is MIIDBA?
MIIDBA is an automated SQL Server health monitoring and alerting product. It helps DBA and operations teams stay ahead of backup, job, capacity, security, high-availability, and performance issues across the SQL Server estate — whether servers run on bare metal, virtual machines, or in the cloud.
MIIDBA is available as:
- Self-hosted (on-premises) — you install and run the web application, repository database, and monitoring agent on your infrastructure.
- Cloud (SaaS) — MIIDBA hosts the web application and repository; you install the Windows agent where it can reach your SQL Server instances.
Self-hosted
A Windows web service hosts the MIIDBA dashboard and APIs. A Windows agent collects health and performance data from the SQL Server instances you register, and writes that data to a SQL Server repository database. You review results, alerts, and trends in a single web interface.
Unlike agentless designs that rely only on remote WMI/SSH, MIIDBA uses a dedicated Windows agent with SQL Server credentials (or the agent service's Windows identity) to run diagnostic queries and return structured results for the dashboard.
Cloud (SaaS)
The cloud offering works in much the same way from the DBA's point of view. The main differences are:
- MIIDBA maintains, upgrades, and runs the web application and repository on hosted infrastructure.
- You install the cloud agent (
MiidbaAgent) on a Windows machine that can reach your SQL Servers; the agent sends collected data to MIIDBA over HTTPS using an ingest URL and API key.
Whichever hosting method you choose
MIIDBA watches registered instances and raises alerts when thresholds or conditions are met — for example stale backups, failed jobs, high CPU or memory, low disk space, unreachable instances or agents, long-running queries, blocking, and deadlocks.
By collecting metrics over time, MIIDBA makes it easier to spot concerns before they become outages: backup gaps, capacity pressure, job failures, and performance hotspots. Daily health email summaries can deliver a 24-hour digest so teams do not need ad hoc checks on every server.
Core areas in the product include:
| Area | Examples |
|---|---|
| Estate overview | Dashboard, instances, databases |
| Backups & jobs | Backup status, SQL Agent jobs and history |
| High availability | Availability Groups, log shipping, replication |
| Capacity | Disk overview, database files |
| Performance | Long-running queries, missing/unused indexes, statistics, Query Store |
| Security | Configuration checks, logins, database users, error log |
| Operations | Alerts, settings, users, agent configuration, licensing |
Planning and prerequisites
This section focuses on self-hosted installation. Cloud customers primarily need network access from the agent machine to SQL Server and outbound HTTPS to MIIDBA.
Installing and configuring MIIDBA is a DBA-oriented task. In many environments it helps to involve Windows administration, networking, and security teams early — especially for service accounts, firewall rules, and SQL permissions.
Step 1: Plan the architecture
You will need three logical components:
| Component | Role |
|---|---|
| Web service (MiidbaWeb) | Hosts the MIIDBA web UI and APIs (Next.js standalone under NSSM — IIS is not required). |
| Repository database | SQL Server database that stores monitoring data, users, configuration, and license state. |
| On-premises agent (MiidbaAgentOnPrem) | Collects data from monitored SQL Server instances and writes to the repository. |
For many smaller estates, all three can run on one Windows server (web + agent on the same machine; repository on that server or a dedicated SQL instance). For larger estates, place the repository on a resilient SQL Server and ensure the agent host can reach every instance you intend to monitor with low latency.
Plan ahead for:
- Which SQL Server instances must the agent reach (on-prem, VM, cloud VNet)?
- Firewall paths between agent ↔ monitored instances, and users ↔ web URL/port.
- Whether the web URL will be
http://hostname:port(LAN) or fronted by HTTPS reverse proxy later. - A durable home for the repository database (backed up; not disposable).
Step 2: Prerequisites checklist
Windows host (web + agent)
| Requirement | Details |
|---|---|
| OS | 64-bit Windows (installer is x64-only) |
| Privileges | Administrator rights to run Setup and install Windows services |
| Disk | Space for the application under Program Files (default C:\Program Files\MIIDBA) plus growth for logs |
| Code signing / Smart App Control | Production builds should be Authenticode-signed; unsigned lab builds may be blocked by Windows 11 Smart App Control |
Repository SQL Server
| Requirement | Details |
|---|---|
| Engine | Microsoft SQL Server 2012 or later (self-hosted does not use PostgreSQL) |
| Database | Empty existing database, or allow Setup to create a new one |
| Auth for Setup | SQL authentication or Windows authentication with rights to connect (and create DB if chosen) |
| Network | TCP connectivity from the MIIDBA host (commonly port 1433, or your instance port) |
| Azure SQL | Supported as a repository target; create the database first — the installer cannot create Azure SQL databases |
Web access
| Requirement | Details |
|---|---|
| HTTP port | Choose an available port (Setup default 8080); Setup can test availability |
| Firewall | Setup can add a Windows firewall rule for Domain + Private profiles |
| Application URL | Use the address browsers and integrations will open (for example http://db-server:8080). localhost only works on the server itself |
Monitored SQL Server instances (post-install)
The agent needs:
- Network reachability to each instance.
- A SQL login or Windows identity (agent service account) with rights to run MIIDBA’s diagnostic queries (see Permissions and Login Setup).
Register instances in Settings → SQL Server instances after installation.
Step 3: What Setup will ask for
During the Windows installer you will:
- Accept the EULA.
- Choose install folder, application URL, and HTTP port.
- Choose existing or create new repository database and test the SQL connection.
- Choose the Windows account for the web service (Local System or a user/service account).
- Create the first administrator (name, email, password).
- Optionally enter a license key (leave blank for a 7-day trial).
- Allow Setup to migrate the schema, seed the admin account and agent, and install
MiidbaWebandMiidbaAgentOnPrem.
When Setup finishes, open the application URL and sign in at /signin.
Post-installation tasks
Before day-to-day use:
- Sign in as the administrator created during Setup.
- Confirm the agent service is running.
- Add at least one SQL Server instance under Settings.
- Configure alert thresholds and (optionally) email delivery / daily health summary.
- Activate a paid license if you are past evaluation (see Licensing).
Next step
Install MIIDBA using the Windows server installer for your release, then proceed to Licensing if you have a production key.
Permissions & Login Setup
The following script creates a dedicated MIIDBA login and grants the minimum required permissions for monitoring. Run it on each target SQL Server instance.
USE [master] GO CREATE LOGIN [MIIDBA] WITH PASSWORD=N'##PASSWORD##', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF CREATE USER [MIIDBA] FOR LOGIN [MIIDBA]; GRANT VIEW SERVER STATE TO [MIIDBA]; GRANT VIEW ANY DEFINITION TO [MIIDBA]; GRANT SELECT ALL USER SECURABLES TO [MIIDBA]; GRANT CONNECT ANY DATABASE TO [MIIDBA]; GRANT EXECUTE ON sys.xp_enumerrorlogs TO [MIIDBA]; GRANT ALTER ANY EVENT SESSION TO [MIIDBA]; GRANT EXECUTE ON sys.xp_logininfo TO [MIIDBA]; USE [msdb] GO CREATE USER [MIIDBA] FOR LOGIN [MIIDBA]; GRANT EXECUTE ON [dbo].[agent_datetime] TO [MIIDBA]; ALTER ROLE [db_datareader] ADD MEMBER [MIIDBA]
Replace ##PASSWORD## with a strong password and store it in your password manager.
Licensing
Licensing differs by deployment profile.
| Profile | How licensing works |
|---|---|
| Self-hosted | Installation license (trial or paid key) on the MIIDBA server. Controls sign-in and agent collection. |
| Cloud (SaaS) | Organization seats managed through the cloud product (trial seats at signup; paid tiers via billing). The self-hosted steps below do not apply. |
This section documents self-hosted licensing.
Evaluation (trial)
- Leave the license key blank during installation to start a 7-day evaluation.
- Trial capacity is limited (including one monitored SQL instance by default).
- Trial start/end is stored in the repository database and on the machine (registry / ProgramData marker). Reinstalling does not reset the trial; deleting only the database is not enough to start over.
When the trial expires, users cannot sign in and the agent stops collecting until you activate a valid paid license (or complete a full trial reset only where your support process allows).
Paid license keys
Paid keys are issued by MIIDBA (sales / license server) in a format such as:
MIIDBA-XXXX-XXXX-XXXX-XXXX
A paid key is bound to one active MIIDBA installation. Separately, the key includes SQL instance seats — the maximum number of monitored SQL Server instances allowed on that installation.
Where to enter a license
You can provide a license in either place:
- Installer — License page — paste the key during Setup (or leave blank for trial).
- Web UI — Settings → License — activate or replace a key after installation.
Online activation
If the MIIDBA server can reach the MIIDBA license API:
- Go to Settings → License.
- Enter the license key.
- Choose Activate.
The installation receives a signed license token and can renew it on a heartbeat schedule so remote suspend/revoke can take effect when connectivity is available.
Offline / air-gapped activation
If the server cannot reach the license API:
- Obtain a signed offline token for your key from MIIDBA (sales or license portal process).
- On Settings → License, enter both the license key and the signed token.
- Activate.
License states
| State | Meaning |
|---|---|
| Valid (trial) | Evaluation active; within trial window and seat limits. |
| Valid (paid) | Paid installation license active; instance seats enforced. |
| Expired | Trial or commercial term ended — sign-in and collection blocked until renewed/replaced. |
| Suspended / revoked | License disabled by issuer — treat as invalid until resolved with sales/support. |
| Update required | Installation must refresh the signed token (for example after a licensing format change). |
Assigning capacity to instances
Self-hosted capacity is measured in monitored SQL Server instances (instance seats), not named user seats.
- Adding instances in Settings consumes available seats.
- If you exceed purchased seats, new instances cannot be licensed for monitoring until you free seats or purchase more capacity.
- The License page shows seats used vs purchased.
Replacing or moving a license
You may need to replace a license if:
- You are moving from trial to paid.
- Sales issued a new key with more instance seats or a new term.
- You are relocating MIIDBA to a new server (deactivate / re-issue per your license agreement, then activate on the new install).
After activating a new key on Settings → License, confirm status shows valid and that instance seats match your purchase. If an old installation still holds the key, activation on a second server may fail until the previous install is released.
What happens when a license is invalid?
- Users see a license warning and cannot complete sign-in for normal use.
- The agent does not collect new monitoring data.
- Existing historical data in the repository remains on disk/database until retention policies apply, but the estate is not actively monitored.
Restore service by activating a valid trial (only if still within the original evaluation window) or a paid key.
Cloud licensing (summary)
Cloud organizations use organization seat licenses (trial, Standard, Enterprise) managed in the cloud product and billing flow — not the self-hosted installation license panel. For cloud customers, see your MIIDBA cloud account and billing documentation.
Alerts
Alerts notify you when collected metrics or events cross thresholds you configure. MIIDBA evaluates alert rules on a short schedule (about once per minute) and raises Warning or Critical alerts. You can review them on the Alerts page and optionally receive email.
Configuring alerts
- Go to Settings → Alerts/Emails.
- Enable or disable each condition.
- Set Warning and Critical thresholds where applicable.
- Optionally add email recipients per alert (or use bulk actions for critical alerts).
- For some database change alerts, maintain an ignore list so noisy databases do not page you.
Alert types and default thresholds
| Alert | Fires when | Default warning | Default critical |
|---|---|---|---|
| CPU Utilization | Host CPU above threshold | 80% | 90% |
| Available Memory | Available memory below threshold | 1 GB | 1 GB |
| Overdue (Full/Diff) Backups | Full/diff backup older than threshold | 24 hours | 24 hours |
| Overdue (Log) Backups | Log backup older than threshold | 24 hours | 24 hours |
| Job Failure | A SQL Agent job fails | (event) | (event) |
| Low Disk Space | Free disk space below threshold | 5 GB | 2 GB |
| Instance Unreachable | No successful SQL connectivity for | 60 seconds | 60 seconds |
| Agent Unreachable | No agent heartbeat for | 300 seconds | 300 seconds |
| Instance Configuration Change | Monitored instance config changes | (event) | (event) |
| Database Configuration Change | Monitored database config changes | (event) | (event) |
| Database Status Change | Database status changes (for example Offline) | (event) | (event) |
| Long Running Query | Query duration exceeds | 60 seconds | 300 seconds |
| Blocking Process | Session blocked longer than | 45 seconds | 60 seconds |
| Deadlock | A deadlock is detected | (event) | (event) |
Event-style alerts do not use a numeric threshold in the UI; they fire when the condition is observed.
Alert lifecycle
| State | Meaning |
|---|---|
| Open | Condition is active (or was active and not yet resolved) |
| Acknowledged | Someone has seen the alert; monitoring continues |
| Resolved | Condition cleared or a user marked it resolved |
Many threshold alerts auto-resolve when the metric returns to a healthy range. Email can be sent when alerts open and when they resolve, depending on your notification configuration.
Email delivery (self-hosted)
Self-hosted installs send alert (and daily health) email through organization SMTP configured on the same Settings → Alerts/Emails tab. Cloud installs use the hosted mail provider. Without working outbound email, alerts still appear in the product UI.
Daily Health Check emails
The daily health check is a scheduled 24-hour summary email — separate from real-time alerts. It helps stakeholders review backups, jobs, capacity, security, and high availability without opening the dashboard every morning.
What it includes
Depending on the sections you enable, the email can cover:
- Summary KPIs and top findings for the last 24 hours
- Backups — overdue or missing backup patterns
- Jobs — failures and notable job outcomes
- Capacity — disk / space pressure
- Security — notable security findings from collected data
- High availability — AG / log shipping / replication concerns
- Trends and instance inventory highlights
- Links back into the MIIDBA UI for follow-up
Real-time paging still belongs in Alerts; use the daily email for a digest.
How to configure it
- Go to Settings → Alerts/Emails → Daily Health Check.
- Enable the schedule.
- Choose send time, timezone, and optionally weekdays only.
- Choose minimum severity (for example INFO, WARNING, or CRITICAL) if offered.
- Toggle which sections to include.
- Add recipient email addresses.
- Save. Use Send now (if available) to test delivery.
Default schedule is commonly 07:00 in the selected timezone (often UTC until you change it).
Requirements
- Outbound email must work (self-hosted: organization SMTP; cloud: platform mail).
- The company must have monitored instances and recent collected data for the sections to be meaningful.
- Background jobs / scheduler must be running on the MIIDBA server (self-hosted web service).
Data collection & Polling
MIIDBA collects monitoring data through a Windows agent. The agent connects to each SQL Server instance you register and runs diagnostic queries on a schedule. Results are stored in the MIIDBA repository (self-hosted) or sent to the cloud ingest API (SaaS).
What gets collected
| Collection | Typical content |
|---|---|
| Full poll | Instance overview, databases, backups, SQL Agent jobs/history/operators, security snapshots |
| Backups | Backup history / last backup freshness |
| Jobs | Job definitions and recent job history |
| High availability | Always On Availability Groups, log shipping, replication |
| Disks | Volume free space (WMI with SQL fallback) and database file sizes |
| Resources | CPU, memory, batch requests/sec, transactions/sec, blocked sessions, poor active sessions |
| Wait stats | sys.dm_os_wait_stats |
| Workload / long-running | Plan-cache long-running queries and related plan data |
| Index recommendations | Missing/unused indexes and database statistics (and related Query Store tops on a longer cadence) |
| Reachability | Lightweight SELECT 1 connectivity check |
| Live query | Short poll for on-demand DMV / Query Store jobs requested from the UI |
Security-related catalog collection inside the full poll is also throttled so it does not run more often than about 5 minutes.
Default intervals (self-hosted / on-premises agent)
These are the typical defaults for MiidbaAgentOnPrem after a standard install:
| Poll | Default interval | Setting name |
|---|---|---|
| Full (inventory + security + more) | 5 minutes | PollIntervalMinutes |
| Backups only | 1 minute | BackupPollIntervalMinutes |
| Jobs only | 1 minute | JobPollIntervalMinutes |
| High availability | 1 minute | HaPollIntervalMinutes |
| Disks / database files | 20 minutes | DiskPollIntervalMinutes |
| Resources (CPU, memory, …) | 1 minute | ResourcePollIntervalMinutes |
| Wait stats | 10 minutes | WaitStatsPollIntervalMinutes |
| Long-running / workload | 5 minutes | LongRunningPollIntervalMinutes |
| Indexes / statistics | 6 hours (360 minutes) | IndexRecommendationsPollIntervalMinutes |
| Reachability ping | 15 seconds | ReachabilityPingIntervalSeconds |
| Live query jobs | 5 seconds | LiveQueryPollIntervalSeconds |
Set an interval to 0 (where supported) to disable that loop. Reachability and live-query intervals are in seconds; set them to 0 to disable.
Cloud agent defaults (for comparison)
The cloud agent ( MiidbaAgent ) uses the same poll types. Shipped defaults commonly differ slightly — for example backups every 2 minutes, jobs every 5 minutes, HA every 5 minutes, long-running every 60 minutes, and index recommendations off until enabled. Always check the agent’s appsettings.json on the machine for the values that apply to your install.
Changing intervals
Poll intervals are configured in the agent’s appsettings.json (under the Agent section), not in the MIIDBA web Settings UI today. After editing the file, restart the Windows agent service for changes to take effect.
Operational tip: Shorter intervals improve freshness (especially backups, jobs, and resources) but increase load on monitored instances and the repository. Prefer the defaults unless you have a specific requirement.
Prerequisites for collection
- The agent Windows service must be running.
- At least one SQL Server instance must be registered under Settings → SQL Server instances (with valid credentials or a suitable Windows service account).
- A valid installation license (self-hosted) or cloud organization seats (SaaS) must allow monitoring.
- The agent host must be able to reach each instance over the network.
Users and Roles
MIIDBA organizes access around organizations, companies, and SQL Server instances.
Roles
| Role | Typical scope | Can change settings / invite users? |
|---|---|---|
| Organization admin | Whole organization | Yes — companies, org-level settings, users |
| Company admin | One or more companies | Yes — within those companies (instances, alerts, invites) |
| Read only | Assigned companies | No — view dashboards and alerts only |
Platform / global administrators (MIIDBA operators) may have additional cross-tenant capabilities in the cloud product; customer installs normally use org and company roles.
Creating the first administrator
- Self-hosted: Setup creates the first local administrator (name, email, password). Sign in at
/signinwith that account. Public self-signup is typically disabled — add more users from Settings. - Cloud: Users can sign up or be invited according to your cloud tenancy; org admins manage companies and seats.
Inviting users
- Go to Settings → Users.
- Add the user’s email (and name).
- Choose Company admin or Read only (or org admin where applicable).
- Save. If the user has no password yet, MIIDBA emails a set password / reset link when mail is configured.
Good practice
- Prefer read only for stakeholders who only need visibility.
- Use a shared distribution list as an alert/daily-email recipient when many people need the same digest — that is separate from interactive user accounts.
- Keep at least two organization or company admins so access is not lost if one account is unavailable.
Feedback, Bugs, User Requests
Use the in-app feedback channel to send feature requests and bug reports directly to the MIIDBA team.
How to submit
- While signed in, open the Send feedback control in the app shell (envelope icon).
- Choose Feature Request or Bug Report.
- Enter your email, a short title, and a description.
- Add optional details (steps to reproduce, expected vs actual, environment).
- Submit.
What to include for bugs
- MIIDBA version / build (and whether cloud or self-hosted)
- Browser and OS
- What you were doing when it failed
- Exact error text or a screenshot
- Instance / page name if relevant (avoid pasting secrets, passwords, or full connection strings)
What to include for feature requests
- The problem you are trying to solve
- How you work around it today
- Why it matters (frequency, risk, time saved)
Other support paths
If email from the app cannot be delivered (mail not configured on a self-hosted server), contact your MIIDBA administrator or sales/support contact for your account. There is no public GitHub Issues link inside the product UI.