Workflows in Practice: Disk Space Monitoring
Five nodes that check a server's disk, record the reading, alert the customer, and archive the run — the first in a series of small CortexBolt workflows built for production use.
A full disk is one of the few failures that stops everything at once. Applications cannot write, databases stop accepting data, and the operating system itself becomes unstable. The failure is completely predictable — disks fill gradually, in plain sight — yet it still takes production systems down, because the checking is left to people, and people are busy.
The fix is not more vigilance. It is a small workflow that does the checking the same way every time, tells someone before the problem becomes an outage, and leaves a record of every run.
The scenario
An administrator wants a disk check that runs on request. One HTTP call starts the workflow. It reads disk usage on the server, writes the reading to a database, notifies the customer of the current utilization, and archives the output of the run.
The business case is broader than one administrator. Any organization that manages Linux servers needs continuous visibility into storage. Done by hand, the checks are inconsistent, easy to skip, and leave no history. Automated, they cost nothing to repeat, run identically every time, and build an auditable record of every execution.
The workflow at a glance
Five nodes, four steps. After the reading is taken, the flow splits into two branches that run side by side: the Alert Sink notifies the customer and ends there, while the Database Job records the reading and continues to a final archive step.
Webhook Trigger
│
▼
OS Job
│
┌─┴─────────────┐
▼ ▼
Database Job Alert Sink
│
▼
Storage Job| Step | Node | Purpose |
|---|---|---|
| 1 | Webhook Trigger | Starts the run on a single HTTP call |
| 2 | OS Job | Reads disk usage from the server |
| 3A | Database Job | Writes the reading to a table |
| 3B | Alert Sink | Notifies the customer |
| 4 | Storage Job | Archives the output of the run |
Step 1 — Webhook Trigger
The webhook is the entry point. The workflow starts when the endpoint receives a request — from an administrator’s terminal today, from a scheduler or another system tomorrow:
curl -X POST https://cortexbolt.example.com/hooks/disk-checkThe trigger has one job: start the run and hand execution to the OS Job. Nothing downstream knows or cares how the run was started, which is exactly what lets the same workflow serve a person, a schedule, and another system without modification.
Step 2 — OS Job
The OS Job executes an operating system command on the server. Here it runs
df -h / to read how much of the root filesystem is in use:
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 100G 82G 18G 82% /The output is parsed down to a single figure: the percentage of storage in use. That number — 82 in this example — is what the rest of the workflow carries forward.
Step 3 — Record and notify, in parallel
Once the reading exists, two things need to happen, and neither should wait for the other.
The Database Job writes the reading to a table — host, timestamp, percentage. One row is a data point. Accumulated over months, the table becomes two things at once: an audit trail of every check that ran, and a history you can chart to see how fast each disk is growing.
The Alert Sink notifies the customer of the current utilization. The message carries the same figure that was just recorded, so what the customer is told and what the database stores can never disagree.
Step 4 — Storage Job
Once the reading is recorded, the run ends at the Storage Job, which archives the complete output of the workflow. This is the layer that supports auditing, reporting, and troubleshooting: when someone asks what the check saw three months ago, the answer is a lookup, not a reconstruction.
Why this is worth automating
The workflow replaces a repetitive manual check with a process that is consistent, observable, and recorded. Operational risk goes down because the check always runs the same way. Reliability goes up because the alert arrives while the problem is still maintenance, not yet an incident.
Five nodes — Webhook, OS, Database, Alert, Storage — and one deliberately small workflow. The shape is what matters: probe, record, notify, archive. Swap the command in the OS Job and the same four steps monitor memory pressure, load, certificate expiry, or backup status. That generality is the reason to build the small version first — and it is where this series goes next.
Workflows in Practice continues with the next small workflow. CortexBolt — the platform these workflows run on — is live and free to start.