Schedule icon
Webhook icon
WorkingDirectory icon
Commands icon
Docker icon
Script icon
Loop icon
If icon
SlackIncomingWebhook icon
Create icon
Log icon

Watch SQL Server tempdb Before It Fills the Instance

Sample SQL Server tempdb usage, compute the used percentage and growth rate, then escalate to Slack and a GitHub issue above your threshold.

Categories
Infrastructure

Diagram unavailable

We could not build the topology for this blueprint. The flow itself is valid, use the YAML on the left to run it.

How it works

  1. hourly_tempdb_watch (io.kestra.plugin.core.trigger.Schedule, cron 0 * * * *) is the fallback net and ships disabled: true, so nothing runs until an operator switches it on. on_demand_watch (io.kestra.plugin.core.trigger.Webhook, keyed) accepts an on-demand sample of a named instance from a monitoring job or a laptop.
  2. usage_workspace (io.kestra.plugin.core.flow.WorkingDirectory) opens one shared filesystem so the sampler, the aggregator, and the recommendation loop all read and write the same files.
  3. capture_tempdb_usage (io.kestra.plugin.scripts.shell.Commands on the io.kestra.plugin.scripts.runner.docker.Docker runner, image mcr.microsoft.com/mssql-tools) writes a tempdb-usage.tsv fixture of six data files and two log rows plus a tempdb-growth.tsv fixture of growth events using heredocs, then runs a best effort sqlcmd against the instance with || true absorbing the exit code. A reachable instance overwrites the fixture with live rows, an unreachable one keeps the flow deterministic.
  4. aggregate_usage (io.kestra.plugin.scripts.python.Script on python:3.12-slim) prefers the live sample, falls back to the fixture, and computes used_pct as the sum of used_mb over the sum of current_size_mb, growth_mb_per_hour from the fixture events, the per-file breakdown, the files above 80 percent, and the AT_RISK or HEALTHY verdict through the outputs protocol.
  5. recommend_hot_files (io.kestra.plugin.core.flow.Loop, concurrencyLimit: 1) runs right after the workspace closes and walks every hot file, with append_recommendation emitting one shrink or growth line per file through the outputs protocol.
  6. check_threshold (io.kestra.plugin.core.flow.If) compares used_pct with usage_threshold_pct. Above it, alert_slack posts the numbers and open_tempdb_issue files a labeled GitHub issue carrying the markdown breakdown and the recommendations. At or below it, log_all_clear records the all-clear.
  7. The errors block alerts Slack whenever the sample or the aggregation breaks, because a dead sampler looks exactly like a quiet instance.

What you get

  • Gateable metrics, verdict, used_pct, growth_mb_per_hour, and total_used_mb are flow outputs any downstream flow can branch on.
  • Early warning where engineers already work, a Slack ping with the used percentage and growth rate, plus a labeled GitHub issue with the per-file markdown table.
  • A recommendation file, one shrink or growth line per file sitting above 80 percent, ready to paste into a change ticket.
  • An audit trail, every execution is a dated record of how full tempdb was and how fast it was growing.

Who it's for

  • Database administrators who need warning before tempdb fills and takes the instance down.
  • SRE and platform teams running shared SQL Server estates who want capacity pressure routed into their existing queue.
  • Anyone who has been paged at 03:00 by a failed tempdb autogrow and wants that conversation moved earlier.

Why orchestrate this with Kestra

tempdb pressure is a slow moving problem that only hurts when nobody is watching. Kestra supplies the loop around it, a disabled-by-default hourly schedule as the safety net, a keyed webhook for on-demand samples, a containerized sqlcmd so the tooling version lives in the flow file, a threshold branch that separates escalation from the all-clear, a per-file recommendation loop, and execution history with the metrics attached. A cron entry on a jump box gives you none of that, it only samples the instance someone remembered to check.

Prerequisites

  • A worker with Docker access, the sampler runs in mcr.microsoft.com/mssql-tools and the aggregator in python:3.12-slim.
  • Network reachability to the SQL Server instance on port 1433 for a live sample. Without it the flow still completes on the bundled fixture, which is what makes it safe to run in CI or on a laptop.
  • A SQL login that can read tempdb.sys.database_files and call FILEPROPERTY.
  • A GitHub token that can open issues in your-org/database-ops (classic PAT scope repo, or fine-grained Issues: write).
  • A Slack incoming webhook for escalation and for failure alerts.

Secrets

  • TEMPDB_WEBHOOK_KEY: key segment guarding the on-demand webhook URL, anyone holding it can trigger a sample.
  • MSSQL_USER: SQL login name used by sqlcmd for the live tempdb sample.
  • MSSQL_PASSWORD: password for that SQL login.
  • GITHUB_TOKEN: token used to open the capacity issue.
  • SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

  1. Add the five secrets to your Kestra namespace.
  2. Run the flow once with the default inputs and confirm verdict, used_pct, growth_mb_per_hour, and total_used_mb in the outputs. The bundled fixture lands above the default threshold, so the first run escalates on purpose.
  3. Point the repository field of open_tempdb_issue at a repository where issues are welcome, then re-run and check the Slack message and the issue body.
  4. Trigger on_demand_watch at /api/v1/{tenant}/executions/webhook/{namespace}/mssql-tempdb-growth-monitor/{TEMPDB_WEBHOOK_KEY}, or enable hourly_tempdb_watch once the worker can reach the instance.

How to extend

  • Watch a fleet by looping over an instance list, one execution per instance, and routing the results into a single digest.
  • Add a second gate on growth_mb_per_hour so a fast growing but still half empty tempdb escalates early.
  • Write the recommendations_md output to a file and ship it to S3 or attach it to the GitHub issue as a capacity artifact.
  • Turn a breach into a red run by adding io.kestra.plugin.core.execution.Fail under check_threshold.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.