Month in Review - November 2025
Published on November 27, 2025 | Written by Andreas
First, we would like to thank all new customers who chose HyperEnv as their self-hosted GitHub runner solution this month. We would also like to thank all our existing customers for their trust and valuable feedback. We are delighted that HyperEnv has struck a chord and are highly motivated to work on small improvements and major features.
Release 3.2.0
We are thrilled to announce HyperEnv 3.2.0, 3.2.1, and 3.2.2 and the following changes.
- Fix: cancel job immediately instead of waiting for timeout in case of spot interruption
- Fix: HOME environment
- Fix: S3 cache server
- Improvement: dashboard shows waiting time in median, p90, and p95
- Improvement: increase reliability of instance state machine
- Improvement: adding maximum look ahead delay
- GitHub Runner 2.330.0
- Latest security patches
- Minor bug fixes
Please upgrade to version 3.2.2 immediatly to avoid service interruptions. Follow our update guide to do so.
Dashboard
We improved HyperEnv’s CloudWatch dashboard. The Delay (sec): Job Created -> In Progress widget shows the delay between a GitHub job being created and the job running on a self-hosted runner managed by HyperEnv. Now, the widget displays the median, 90th percentile, and 95th percentile of the delay, which is more meaningful than the average, maximum, and minimum that were shown before.
New Configuration Parameters
We are introducing two configuration parameters.
StateMachineTimeout: The timeout for the job state machine and instance state machine in seconds.
We recommend calculating the value for the StateMachineTimeout parameter with the following formula.
StateMachineTimeout = (GitHubWaitTimeout + GitHubJobTimeout + MaxLookAheadDelay + 60) * 60
MaxLookAheadDelay: The maximum delay the instance state machine waits before launching an EC2 instance to run an upcoming job in minutes. Only applicable when LookAhead = true.
Spot Interruptions
Utilizing EC2 spot instances is key when it comes to keeping the infrastructure costs for self-hosted GitHub runners on AWS to a minimum. Unfortunately, the likelihood of spot interruptions increased dramatically during the past weeks. We observe that up to 20% of spot instances are getting interrupted, causing cancelled GitHub jobs.
We want to highlight, that spot instances should only be used for GitHub jobs that can easily be re-run in case of an interruption. So, for example, using spot instances is fine for running unit tests, linting, building deliverables, and many more. In contrast, spot instances should not be used to execute deployments, like running Terraform configurations.
Besides that, we are working on a feature allowing HyperEnv to automatically restart GitHub jobs that have been cancelled due to a spot interruption. We are shipping the first improvement related to this with release 3.2.0. From now on, the HyperEnv service will gracefully terminate the GitHub runner in case of a spot interruption. That results in GitHub jobs getting cancelled immediately when the EC2 instance shuts down. Formerly, many GitHub jobs got stuck until running into a 15-minute timeout. We plan to ship the rest of the feature next month.
Feedback
We would appreciate your feedback to help us improve HyperEnv. What feature do you miss? What is particularly important to you when it comes to hosting GitHub runners on AWS? hello@hyperenv.com