Cloud data platforms become hard to trust when monitoring, maintenance, deployments and recovery are treated as separate jobs. The fix is usually not another dashboard. It is a small operating model that makes ownership and decisions visible.
1. Define health
“The database is up” is not enough. A service can accept connections while a pipeline is late, data is stale, queries are blocked or storage is close to a limit.
For each important workload, write down:
- the user or business outcome it supports;
- the owner for the application and data path;
- what availability, freshness or completion means; and
- which failures need immediate attention.
2. Observe useful signals
Use four signal layers:
| Layer | Useful questions |
|---|---|
| Service | Can users and downstream systems complete the work? |
| Resource | Are CPU, data space, log write or connections approaching a boundary? |
| Workload | Which queries, locks or jobs are creating pressure? |
| Change | What deployment or configuration change happened beforehand? |
Azure Monitor, Log Analytics, Query Store and DMVs each answer different questions. Choose the simplest signal that explains the risk. A threshold is a starting point, not a universal truth: tune it against normal workload behaviour and false positives.
3. Respond safely
Every high-value alert should link to a tiny playbook with an owner, first checks, escalation point and evidence location. The first responder should not have to search three systems to understand what fired.
Separate detection from remediation:
- Detect: collect metrics, logs and query history.
- Triage: gather context and classify the issue.
- Act: run only pre-approved, reversible actions automatically.
- Verify: confirm the service improved and record the outcome.
Use least-privilege identities, validate inputs and make runbooks idempotent. “The script ran” is not the same as “the service recovered.”
4. Control change
Index maintenance, statistics updates, integrity checks, retention changes and scaling are production changes. Give each one a reason, owner, window, stop condition and audit trail.
For recurring SQL work, measure first, prefer targeted operations, avoid peak periods and record start time, end time, object, result and errors. For pipelines, distinguish transient dependency failures from bad inputs or permission problems; retries should not hide permanent failures.
5. Learn and plan
Review storage, compute, log generation, connections, pipeline duration and queue depth as trends. Pair them with expected growth and record a decision: tune, scale, archive, redesign or accept the risk.
After an incident or material change, ask:
- Did we detect user impact early enough?
- Did the alert contain enough context?
- Was the response safe and complete?
- Did a recent change or capacity trend contribute?
- What one control will improve before the next review?
Quick-start checklist
- Name owners for critical workloads
- Write a one-page health definition
- Keep only alerts with an owner and action
- Automate reversible actions first
- Review capacity and recovery regularly
Reference index · current Microsoft Learn links checked 31 August 2026
About Jae Pasha
Jae is a London-based Cloud, Data and AI Engineer and founder of Cequor. Read the author profile or connect on LinkedIn.
View Jae’s contractor profile for public information about his cloud, data, SQL reliability, monitoring and AI automation work.