Steadybit logoResilience Hub
Try SteadybitGitHub icon
Steadybit logoResilience Hub

Time Travel

AttackAttack
Change the system time by the given offset
Targets:
Hosts
Install now

Time Travel

Change the system time by the given offset
AttackAttack
Targets:
Hosts
Install now

Time Travel

AttackAttack
Change the system time by the given offset
Targets:
Hosts
Install now

Time Travel

Change the system time by the given offset
AttackAttack
Targets:
Hosts
Install now
Go back to list

Introduction

Changes the clock time of a host.

Warning:
This action may cause unwanted side effects. Use with caution. E.g. Other software might have hiccups when system time changes, vital access tokens might expire, etc.

Use Cases

  • Change the time of a host to a specific time.
  • Test your application's ability to handle time changes, like summer winter / time changes.
  • Check for certificate expiration.

Parameters

ParameterDescriptionDefault
DurationHow long should the clock be modified30s
OffsetThe offset that will be added to the current time.1s
Disable NTPPrevent NTP from correcting time during attack.true

Useful Templates

See all
Certificate TLS/SSL expiry

Turn time forward and check whether your TLS/SSL certificates are valid.

Motivation

Noticing the TLS/SSL certification expiry too late is one problem you can easily avoid by frequently checking your expiry dates. While observability tools already handle this job nicely, you can't know whether they are working in your environment. With this experiment, you can turn the time forward to check whether your HTTPS endpoint works at a given date in the future. Additionally, you can configure one of the observability integrations to validate your observability tool's alerting.

Structure

First, we validate that the given HTTPS endpoint is working today. Next, we will travel with the host in time to validate that the HTTPS endpoint continues to work on a given date. If the TLS/SSL certificate has already expired at that date, the HTTP check will throw failures.

Warning

Please be aware that we will manipulate the time for a given host. Applications running at that host may struggle to deal with the change in the clock correctly, and you may experience other side effects.

Certificate Expiry
Hosts
Certificate TLS/SSL expiry for Kubernetes deployment

Turn time forward and check whether your TLS/SSL certificates are valid.

Motivation

Noticing the TLS/SSL certification expiry too late is one problem you can easily avoid by frequently checking your expiry dates. While observability tools already handle this job nicely, you can't know whether they are working in your environment. With this experiment, you can turn the time forward to check whether your HTTPS endpoint works at a given date in the future. Additionally, you can configure one of the observability integrations to validate your observability tool's alerting.

Structure

First, we validate that the given HTTPS endpoint is working today. Next, we will travel with the host in time to validate that the HTTPS endpoint continues to work on a given date. If the TLS/SSL certificate has already expired at that date, the HTTP check will throw failures.

Warning

Please be aware that we will manipulate the time for a given Kubernetes node. Containers running at that host may struggle to deal with the change in the clock correctly, and you may experience other side effects.

Certificate Expiry
Hosts
Kubernetes cluster

More Host Actions

See all
Start Using Steadybit Today

Get started with Steadybit, and you’ll get access to all of our features to discover the full power of Steadybit. Available for SaaS and on-prem!

Are you unsure where to begin?

No worries, our reliability experts are here to help: book a demo with them!

Statistics
-Stars
Tags
Host
Kubernetes
Homepage
hub.steadybit.com/extension/com.steadybit.extension_host
License
MIT
MaintainerSteadybit
Install now
Steadybit logoResilience Hub
Try Steadybit
© 2025 Steadybit GmbH. All rights reserved.
Twitter iconLinkedIn iconGitHub icon