In an attack-defense CTF, a checker is an automated script the game server runs against every team's services each tick. It stores a fresh flag, reads back recent ones and uses normal features like a real user. SLA (service level agreement) is the availability score that results: you earn it only for ticks where your service is rated UP.
Checker, SLA and tick: the definitions
Every attack-defense CTF gives each team an identical vulnbox running several vulnerable services. Teams patch their own copy and capture flags from everyone else's. Three terms describe how the game keeps score:
| Term | What it is | Who controls it |
|---|---|---|
| Checker | One script per service that tests each team's copy, every tick | Organizer (written by the service author) |
| SLA | Points or a multiplier earned for each tick a service is rated UP | Scoring rules, published before the game |
| Tick | A fixed scoring interval, often 60 to 180 seconds | Game server clock |
The term comes from IT operations, where a service level agreement promises availability. In a CTF it means the same in miniature: keep the service working for real users, or lose points.
How a checker tests a service each tick
A checker never attacks anything. It behaves like an ordinary customer of the service, in three steps:
- Store. It plants this tick's flag the way a user saves data, for example as a private note behind an account.
- Retrieve. It reads back the flags it planted in recent ticks, proving the service kept its data and no patch wiped it.
- Use. It exercises features unrelated to flags, such as search or registration, so a team can't strip the service down to a bare flag store.
The checker then reports one status per team, per service, per tick:
| Status | Typical trigger | What the team should check |
|---|---|---|
| UP | All three steps passed in time | Nothing; keep it that way |
| MUMBLE | Service answers, but a feature returns errors or wrong output | The last patch; it probably broke legitimate behavior |
| CORRUPT | Service works, but flags from earlier ticks are gone | Data loss from a restart, reset or overly strict cleanup |
| DOWN | No connection, or no answer before the timeout | Crashed process, firewall rule or exhausted resources |
Status names vary between game servers, and some add a "recovering" state. Whatever the labels, the rules should say exactly which statuses earn SLA.
Why teams can't just allow the checker and block everyone else. Well-designed checkers look like any other client: same game network, realistic data, varied behavior. Filtering by fingerprint is a gamble that usually ends in MUMBLE.
How ticks and rounds work
A tick is the heartbeat of the game. In a typical setup each tick runs like this:
tick starts → game server plants a new flag in every service on every vulnbox
during the tick → checkers run against every team, spread across the interval
→ teams submit flags captured from rivals
tick ends → statuses and captures are scored; the scoreboard updates
example: 120 s ticks, flag lifetime 5 ticks
a flag stays valid for 10 minutes
an 8-hour game has 240 ticksMany events use "tick" and "round" interchangeably; some group ticks into larger rounds, such as releasing a new service in round two. Shorter ticks reward automation. Longer ticks give checkers headroom and suit student teams.
SLA points: the math at concept level
Rule sets differ, but most use one of two shapes. The additive model awards a fixed amount per UP tick and adds it to attack and defense points. The multiplier model scales a service's attack and defense points by the share of ticks it was UP:
additive: service score = attack + defense + (UP ticks × SLA points)
multiplier: service score = (attack + defense) × (UP ticks ÷ total ticks)
worked example (multiplier, 240 ticks):
Team A keeps the service UP for 228 ticks → SLA 0.95
attack + defense = 1,200 → 1,140 points
Team B switches it off for 60 ticks to stop
leaks, so it loses fewer flags → SLA 0.75
attack + defense = 1,300 → 975 pointsTeam B defended better on paper and still finished 165 points behind. That is the point of SLA: patching properly beats hiding. For players, it rewards backups, root-cause fixes and watching checker status every tick; our attack-defense page covers team roles and preparation. For how SLA compares with other scoring systems, see CTF scoring.
Common organizer pitfalls
Many A/D disputes trace back to the checker, not the services. The most common mistakes:
- Timeouts that are too tight. Latency turns a slow but healthy service DOWN. Leave margin and allow one retry inside the tick.
- Counting checker errors against teams. If the checker itself crashes, log an internal error and award or void that tick for everyone.
- Never testing against patched services. A correct patch that changes an error message can trip a brittle checker. Playtest with several patched versions.
- Checking only the flag path. Teams will delete every feature the checker doesn't touch.
- Predictable checker traffic. Fixed usernames, timing or headers let teams filter the checker. Randomize data and spread runs across the tick.
- Silent statuses. Give a short reason, such as "flag from tick 211 missing", without exposing checker logic.
- Unpublished rules. Status meanings, timeouts, flag lifetime, the SLA formula and the outage policy belong in the rules before the first tick. Start from our CTF rules template.
Building checkers yourself or running a managed event
Writing a checker is part of writing a service: every service needs a working exploit, a correct patch and a checker that passes the patch. Open-source game servers exist, but you still build and operate the vulnboxes, VPN and checkers yourself. Attack-defense vs jeopardy covers the staffing involved.
Focus on the services, not the referee. CTF7 runs attack-defense CTFs as managed events, or our challenge development team can design, build and test services for you. Ask us which plan fits your event.
Related terms
- Vulnbox: the identical machine each team defends.
- Tick: the scoring interval of an A/D game.
- Dynamic flag: a flag unique to one team (one player in solo events).
- Flag format: the pattern flags follow, such as
CTF7{This_is_an_example_flag}.
Browse the full CTF glossary or compare every format in CTF formats explained.
