Cost and alert report
RunsOn takes cost control seriously, since you will be tempted to use beefy runners to expedite your workflows.
Cost control
CloudWatch alarm if daily usage goes over threshold
RunsOn automatically creates a CloudWatch alarm, which will be triggered if the daily number of minutes consumed goes over a threshold that you define (default: 4000 minutes/day).
Automatic termination to avoid dangling resources
All instances are bootstraped with 2 watchdogs, to ensure they are not left running even if GitHub doesn’t send the completion webhooks (this happens).
- instance will automatically terminate itself after 10 minutes, if a workflow job has not been scheduled on the machine.
- instance will automatically terminate itself after 12 hours, no matter whether a workflow is still running on the machine.
On the server side, a cleanup process is executed every 2 minutes, and will terminate any instance that has not been tagged with runs-on-job-started=true
after 15 minutes. This tag is set by the agent on the instance, when a job has started processing. This additional protection is useful in case the agent can’t even start (e.g. you are using a custom AMI and somehow disabled cloud-init, etc.) or misbehaves for any reason.
Cost reports right in your inbox
RunsOn automatically reports daily costs for the RunsOn resources. Those are sent to the email configured at installation time:
CloudWatch metrics
RunsOn publishes the number of minutes consumed, under the CloudWatch Metric namespace RunsOn
. You can thus graph and specify custom CloudWatch Alarms for those metrics.
This is an area that will see improvements in the near future, with additional metrics for CPU and Memory usage for your workflows.
Alerts
With GitHub Action you cannot (currently) easily see the reason of a failure, without looking at the RunsOn application logs.
That’s why RunsOn automatically reports errors by sending them to the configured email.
In case lots of errors occur in a short time, errors will be batched in a single email: