Skip to main content
By the end of this tutorial, you will have traced a production incident from a 500 error all the way back to the git commit that caused it, using only Kosli CLI queries against the public cyber-dojo organisation.
Prod cyber-dojo is down with a 500
https://cyber-dojo.org is showing a 500 error. It was working an hour ago. What changed?

​
Prerequisites

​
Setup

The cyber-dojo Kosli organisation is public, so any authenticated user can read its data:

​
Start with the environment

https://cyber-dojo.org runs in an AWS environment that reports to Kosli as aws-prod. Get a log of its recent changes:
The environment has accumulated many snapshots since this incident occurred. To focus on the relevant ones, scope the log to snapshots 176 and 177:
You should see:
These two snapshots are part of the same : creator:b7a5908 started in snapshot #176, and creator:31dee35 stopped in snapshot #177. The new artifact arrived just before the 500 error — that is the one to investigate.

​
Dig into the artifact

Get the full history of creator:b7a5908, using the fingerprint prefix from snapshot #176:
You should see:
The artifact was deployed to aws-prod at 16:51 — right when the incident began. The output includes a direct link to the git commit.

​
Follow to the commit

Open the commit URL from the output:
cyber-dojo github diff
A simple typo in app.rb — an extra s inserted into the method name. The function is called respond_to, not responds_to. That one character caused the 500 error.

​
What you’ve accomplished

You traced a production 500 error back to a specific git commit — without any direct access to aws-prod. By querying the environment log and artifact history in Kosli, you identified exactly which deployment introduced the incident and which code change caused it. From here you can:
Last modified on March 10, 2026