How it works
A ride is a live cloud environment with something wrong in it. You get the symptom, not the cause. You have real credentials and a clock.
01
You are dropped into a live environment that is already running and already broken. Nobody tells you what was changed. You get what an on-call engineer gets: a symptom, access, and the same tools you would have at work.
02
Real logs, real metrics, real infrastructure. You read what is actually there rather than a description of it, and the misleading details are misleading in the same way they are on a bad afternoon in production.
03
Diagnose, remediate, recover. There is no answer key and no hint button. Every action you take is recorded, including the ones you undo, because what you tried is part of what you know.
04
Technical execution and operational judgement are scored separately. Restoring the service matters. So does how long diagnosis took, how much you touched to get there, and whether you could say afterwards what had actually failed.
05
One result is a data point. Readiness is a direction. Scores accumulate into a profile that shows which kinds of failure you handle well and which ones to practise before they find you at work.
Short, untimed, repeatable. For learning and experimenting — break it, fix it, break it differently.
Longer, timed, scored. For proving capability, to yourself or to someone who is deciding something about you.
A ride is not a harder challenge. It is the same kind of problem with the clock running and no retries.
All eight are real Shakeride environments, from five minutes to ninety.
The web application is unreachable. The platform reports no running copies of the service, and the traffic router marks every target unhealthy. The most recent release points at a build that was never published. The expected configuration is documented on the resources themselves. Restore service.
20 min · level 3
A business workflow accepts every request and reports it as started, then fails on its first step with an access error. The queue it writes to and the worker behind it both exist and look healthy. A leftover worker from an earlier release is connected to nothing. Find what is being denied and restore the chain.
15 min · level 2
The event router reports every delivery as successful, but the messages never arrive at their destination. The routing rule and its target are intact. A second, unused destination exists nearby. Explain the gap between reported success and actual delivery, then close it.
15 min · level 2
Malformed orders disappear after a few retries instead of landing somewhere a human can review, and nobody was alerted when processing stalled. A second worker with a very short time limit also exists. Restore both containment and visibility for messages that cannot be processed.
25 min · level 3
Looking up a customer by email is slow and rejecting requests under ordinary load, while expired session records accumulate instead of being cleaned up automatically. A monitor on write capacity exists but has never fired. The expected settings are documented on the resource itself.
20 min · level 3
Traffic keeps going to the primary region even though the standby is healthy and should have taken over. Health checks and routing rules exist, but nothing shifts when the primary fails. A second, near-identical set of records exists. The operations team keeps the expected configuration on a dashboard. Restore automatic failover.
45 min · level 4
External researchers report that they can list and download files from a data store without any credentials. Public-access settings are inconsistent across the account, and a second store with a similar name exists. Identify the unintended exposure and close it.
5 min · level 1
New orders stop flowing end to end: the intake queue grows, the order count stalls, and customer notifications never fire. Several workers and tables from earlier releases are still around. Every break in the path must be found — repairing three of the four changes nothing.
90 min · level 5
Kubernetes, infrastructure drift and cost rides are in development.
| Dimension | What it measures | Why it matters |
|---|---|---|
| Technical accuracy | Whether the system actually works again, verified by the environment itself. | It is the floor, not the ceiling. Everything else assumes it. |
| Time to diagnosis | How long until the actual cause was identified. | In an incident, the clock runs from the first alert, not the first fix. |
| Time to recovery | How long until service was restored for users. | It is the number the business feels and the one reported afterwards. |
| Safety of actions | Whether the steps taken risked data, availability or a wider outage. | A fix that could have made it worse is a fix that got lucky. |
| Unnecessary actions | Changes made that had no bearing on the problem. | Every extra change is another thing to explain and another thing to undo. |
| Root cause understanding | Whether the cause was identified rather than the symptom suppressed. | A restart that works is not the same as knowing why it was needed. |
Shakeride provides the cloud account. Nothing is billed to you and nothing you break belongs to anyone else.
No AWS account required. No surprise cloud bill.