Break a synthetic job. Inspect the evidence.

Run four synthetic Python examples in a dedicated Watchdog test job: normal completion, an overdue run, a repeated tool cycle and legitimate repetition with progress. You need Python 3.10 or later, the public SDK, a verified account and a telemetry key. No model calls or private backend checkout are required.

Download the complete lab.

Download Failure Lab 0.1.2 · SHA-256 checksum · Start free

Unpack the archive and follow its README. Its requirements install watchdog-agent-sdk from PyPI. It contains every example, the shared support module, dependencies and complete setup instructions. From the extracted watchdog-failure-lab-0.1.2 directory:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt
python -m pip check

Create one dedicated synthetic job.

In Register a job, create a new agent and job with slug failure-lab, environment failure-lab, no schedule, a 180-second maximum runtime, progress monitoring off and loop repetitions 4. Keep automatic cancellation and retry off, and control/outcome URLs blank. The README lists every setting. Use a separate test account if your free account already has two real jobs; leave real monitoring unchanged.

In Connect, create a dedicated telemetry key. Optionally configure your email recipient in Settings and send a test alert. Use destinations you control: the two failure fixtures can produce real monitoring emails.

export WATCHDOG_URL="https://withwatchdog.com"
export WATCHDOG_LAB_JOB="failure-lab"
export WATCHDOG_LAB_CONFIRM="synthetic-only"
python examples/successful_run.py
python examples/overdue_run.py
python examples/tool_loop.py
python examples/legitimate_repetition.py

Each command prompts for the telemetry key without echoing it. Allow about seven minutes for the full sequence. The scripts send only synthetic telemetry for the selected job, read their own runs and complete each fixture after observation. They do not edit jobs, provision infrastructure, call models or send control commands.

Expected results and evidence.

Each command prints timestamped JSON and writes a result file. A missing result or expired wait is INCONCLUSIVE, never PASS. The README explains exit codes, cleanup and what to send support.

Check incidents and actual notifications separately.

The public run API returns current findings. A finding alone does not prove that an independent check persisted an incident or that an email arrived. Keep the dashboard closed while the examples wait. Afterward, match the printed run IDs in Incidents: expect one runtime incident and one loop incident, possibly resolved after cleanup. Check delivery records and your inbox separately if alerts are enabled.

After recording the results, pause only the dedicated lab job and revoke its test key. Synthetic history follows the existing retention policy. The test environment and synthetic markers keep these examples out of normal customer activation metrics.

What these examples do not prove.

They exercise four specified event sequences and deterministic rules. They do not measure production accuracy, semantic correctness, universal loop detection, zero false positives or benchmark superiority. An overdue fixture demonstrates missing completion beyond a deadline; it does not establish that a process crashed. Real progress signals must represent meaningful completed work. The lab does not test recovery, missed schedules or billing.