Script Triggers
Run a script automatically when a server metric crosses a threshold, with duration, cooldown controls, and a full audit trail.
Script Triggers
A Script Trigger ties a saved script to a live server metric. When the metric crosses a threshold you define, Devpilot waits out a cooldown window and then runs the script for you. It's the bridge between Server Monitoring and Scripts and Automation: observe a symptom, react with a fix.
Common uses:
- Run a log-cleanup script when disk usage stays above 85%.
- Restart a worker when memory usage crosses 90%.
- Fire an on-call escalation script when a managed service is reported down.
A trigger runs the script as-is, with no arguments. If your remediation needs inputs (a Slack URL, an API token), bake them into the script or reference them via Script Secrets.
What You Configure
Each trigger attaches a script to a single condition on a specific server. You pick the script to run, the metric to watch (CPU usage, memory usage, disk usage, or service down), the operator and threshold to compare against, and you can give the trigger an optional name so it's easier to recognise later.
Two timing controls keep the trigger from firing impulsively: a duration (how long the condition must hold before the trigger fires — defaults to 5 minutes) and a cooldown (the minimum minutes between firings, defaults to 30). Each trigger has an Active toggle so you can pause it without deleting it, and the detail view shows the most recent firing time and total number of times the trigger has fired.
Creating a Trigger
Open Monitoring Triggers
From a server's dashboard, open the Triggers section and click Add Trigger.
Select a script
Pick any script saved to this server. The trigger runs the script exactly as-is — there are no per-trigger arguments.
Define the condition
Choose a metric, operator, and threshold. For example, "Disk Usage (%) greater than 85" fires when disk usage exceeds 85 percent.
Tune the timing
- Duration — How long the condition must stay true before the trigger fires. A short CPU spike shouldn't kick off a cleanup job; pick a duration that matches your tolerance. Defaults to 300 seconds (5 minutes), and accepts anything from immediate to one hour.
- Cooldown — Minimum minutes between firings. If your remediation takes a while to reflect in metrics, a longer cooldown prevents back-to-back runs. Defaults to 30 minutes, with a maximum of a day.
Activate
Leave the trigger active and save. Devpilot now evaluates it against the same metrics you see in the Monitoring dashboard.
Operators
Devpilot supports five comparison operators:
| Operator | Meaning |
|---|---|
| Greater than | Fires when the metric is above the threshold. |
| Greater than or equal to | Fires when the metric is at or above the threshold. |
| Less than | Fires when the metric is below the threshold. |
| Less than or equal to | Fires when the metric is at or below the threshold. |
| Equal to | Fires when the metric matches the threshold. Uses a small tolerance so floating-point metrics don't miss equality by a rounding error. |
Supported Metrics
Percentage of CPU used across the server, as reported by the monitoring agent. Pair a high threshold with a longer duration to ignore momentary bursts.
Percentage of RAM in use. Good for triggering worker restarts, cache flushes, or OOM-prevention scripts.
Percentage of the server's primary disk used. Pair this with a log-rotation or temp-cleanup script to keep things from filling up.
Fires when a managed service is reported down. Useful for "restart the service" or "restore last good config" scripts.
How Firing Works
Whenever fresh metrics come in for a server, Devpilot walks through every active trigger on that server:
- Check the metric — If the trigger's metric isn't present in the latest sample, skip it.
- Respect the cooldown — If the last firing was inside the cooldown window, skip to avoid double-firing.
- Compare against the threshold — Using the operator you picked.
- Confirm the duration — The condition must have held for the full duration you set.
- Fire — Start the script on the server and update the trigger's last-fired timestamp and count.
Every firing shows up in the script's regular execution history, tagged so you know the run came from a trigger. You can audit both the trigger configuration and the actual outputs in one place.
Real-World Examples
Low-disk cleanup — Watch disk usage and run a log-rotation script when it holds above 85% for five minutes. Use a 60-minute cooldown so cleanups don't stack on top of each other.
Memory-pressure worker restart — Watch memory usage, fire a "restart queue workers" script once it's above 90% for two minutes, with a tight 15-minute cooldown so the restart happens promptly if memory climbs again.
Service-down paging — When a monitored service is reported down, immediately run a PagerDuty notification script. A short duration gets the page out quickly, while a 10-minute cooldown prevents re-paging while you're already responding.
Auditing Trigger Runs
The trigger itself keeps a running summary: the timestamp of the most recent firing and the total number of times it has fired since creation. For per-run detail — output, exit code, duration — open the script's execution history, where every trigger run appears as a standard execution record.
Limits and Constraints
- Duration must be between 0 seconds and 1 hour.
- Cooldown must be between 1 minute and 1 day.
- Trigger names are capped at 100 characters.
- Each trigger runs its script without arguments — use Script Secrets or hard-coded values in the script body for any inputs it needs.
Troubleshooting
| Problem | Likely cause |
|---|---|
| Trigger never fires | The trigger is inactive, cooldown is still active, or the metric hasn't been reported yet. |
| Trigger fires too often | Duration is too short, or cooldown is too small. Increase both. |
| Metric comparison looks wrong | Double-check the operator and threshold. The "equal to" operator uses a small tolerance. |
| Script runs but does nothing useful | The script itself needs fixing — triggers only start it. Check the execution history. |
| Multiple triggers fire back-to-back | Each trigger has its own cooldown; two triggers on the same metric will each fire once. |
A trigger can run scripts at any hour without human review. Keep remediation scripts idempotent and safe to run repeatedly, and pair risky triggers with a non-trivial cooldown so a metric oscillating around the threshold doesn't cause a storm.
Next Steps
Server Monitoring
See the metrics that drive triggers in real time.
Script Workflows
Promote a single trigger script to a multi-step remediation workflow.
Scripts and Automation
Review the fundamentals of building reliable, idempotent scripts.
Script Secrets
Give trigger scripts access to credentials without hard-coding them.
Script Workflows
Chain scripts together with conditional branching, run history, and optional scheduling so an entire sequence runs as a single coordinated job.
Script Webhooks
Turn any script into a secure HTTP endpoint. Trigger scripts from GitHub, monitoring services, or any external system with token auth, IP allowlists, and HMAC signatures.