How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Failure self-alert — Automation Patterns

Day 18 · ~12 min●

Scheduled at 9am, fails at 9:00:03, no human watching. By the time you notice — tomorrow morning when the report you expected isn't there — 24 hours of nothing. The fix: the script alerts you when it crashes.

Wrap the chain in try/except. On unrecoverable failure, send yourself an email with the error class:

python

import os
recipient = os.environ.get("USER_EMAIL", "you@example.com")

try:
    # ... the chain ...
    raise RuntimeError("forced for demo")    # simulate failure
except Exception as e:
    toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
        "recipient_email": recipient,
        "subject": f"[zuzu-day-18] script failed: {type(e).__name__}",
        "body": f"error: {e}\nclass: {type(e).__name__}",
    })
    raise    # re-raise so the run is marked failed

The send happens before re-raising — alert lands in your inbox, then the original exception propagates. Future-you reads the email at 9:01am and starts debugging.

Why send to yourself and not Slack?

Email and Slack both work. We use Gmail self-send here because (a) Gmail is in your stack already, (b) email is universally accessible — Slack workspaces come and go, your email doesn't, (c) the lesson stays in 7 supported tools.

In a real workflow you might use whatever notification channel you live in. The pattern is identical — send a structured failure message to a channel you watch.

And the raise after sending — why both?

The send is additional; the original error must still terminate the run. Without raise, the script ends with status "success" because we caught everything. The scheduler thinks the run worked. With raise, the original exception propagates after the alert is sent — the scheduler logs the failure, retries appropriately, and you have a notification plus a real failure status.

Failure self-alerts

The shape

python

try:
    do_the_chain()
except Exception as e:
    notify_failure(e)
    raise

Three lines around the chain. The notify_failure is a tool call (Gmail self-send, Calendar event create, Tasks create — pick your channel). The trailing raise re-throws the original error.

What to put in the alert

Keep it parseable, even from your phone at 3am:

Subject: [script-name] failed: ClassName — at-a-glance triage
Body: error class, error message, last log line if available

python

body = f"""
script: {SCRIPT_NAME}
run_at: {datetime.utcnow().isoformat()}Z
error_class: {type(e).__name__}
error_message: {e}
last_step: {last_step_seen}
""".strip()

Three lines of context tell you: which script failed, when, what kind of error, where in the chain it happened. Enough to know whether to fix tonight or tomorrow.

Don't alert on every transient retry

The alert is for unrecoverable errors — the ones that survived your retry loop. Transient errors that retry-and-succeed shouldn't ping you; they're noise.

python

try:
    with_retry(do_the_chain)    # retries internally on transient
except Exception as e:
    # only fires when retries exhausted
    notify_failure(e)
    raise

The retry loop is the gate. Alert only on what it lets through.

Don't alert from inside the alert

If notify_failure itself fails (Gmail down, auth expired), don't infinite-loop:

python

def notify_failure(e):
    try:
        send_email(subject=..., body=...)
    except Exception:
        # alert system is down — log and give up
        print(f"COULDNT_ALERT: {type(e).__name__}: {e}")

Log to stdout as a last-resort breadcrumb. The scheduler's run log still captures it.

Alert on the summary, not each item

A partial-failure loop processes 100 items, 7 fail. Don't send 7 emails — send one with the count and the failed IDs.

python

if results["fail"] > 0:
    notify(f"{results['fail']} of {len(items)} failed: {failed_ids}")

One actionable notification beats 7 panicky ones.

Day 18 · ~12 min●

Wrap the chain in try/except. On unrecoverable failure, send yourself an email with the error class:

python

import os
recipient = os.environ.get("USER_EMAIL", "you@example.com")

try:
    # ... the chain ...
    raise RuntimeError("forced for demo")    # simulate failure
except Exception as e:
    toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
        "recipient_email": recipient,
        "subject": f"[zuzu-day-18] script failed: {type(e).__name__}",
        "body": f"error: {e}\nclass: {type(e).__name__}",
    })
    raise    # re-raise so the run is marked failed

The send happens before re-raising — alert lands in your inbox, then the original exception propagates. Future-you reads the email at 9:01am and starts debugging.

Why send to yourself and not Slack?

In a real workflow you might use whatever notification channel you live in. The pattern is identical — send a structured failure message to a channel you watch.

And the raise after sending — why both?

Failure self-alerts

The shape

python

try:
    do_the_chain()
except Exception as e:
    notify_failure(e)
    raise

Three lines around the chain. The notify_failure is a tool call (Gmail self-send, Calendar event create, Tasks create — pick your channel). The trailing raise re-throws the original error.

What to put in the alert

Keep it parseable, even from your phone at 3am:

Subject: [script-name] failed: ClassName — at-a-glance triage
Body: error class, error message, last log line if available

python

body = f"""
script: {SCRIPT_NAME}
run_at: {datetime.utcnow().isoformat()}Z
error_class: {type(e).__name__}
error_message: {e}
last_step: {last_step_seen}
""".strip()

Three lines of context tell you: which script failed, when, what kind of error, where in the chain it happened. Enough to know whether to fix tonight or tomorrow.

Don't alert on every transient retry

The alert is for unrecoverable errors — the ones that survived your retry loop. Transient errors that retry-and-succeed shouldn't ping you; they're noise.

python

try:
    with_retry(do_the_chain)    # retries internally on transient
except Exception as e:
    # only fires when retries exhausted
    notify_failure(e)
    raise

The retry loop is the gate. Alert only on what it lets through.

Don't alert from inside the alert

If notify_failure itself fails (Gmail down, auth expired), don't infinite-loop:

python

def notify_failure(e):
    try:
        send_email(subject=..., body=...)
    except Exception:
        # alert system is down — log and give up
        print(f"COULDNT_ALERT: {type(e).__name__}: {e}")

Log to stdout as a last-resort breadcrumb. The scheduler's run log still captures it.

Alert on the summary, not each item

A partial-failure loop processes 100 items, 7 fail. Don't send 7 emails — send one with the count and the failed IDs.

python

if results["fail"] > 0:
    notify(f"{results['fail']} of {len(items)} failed: {failed_ids}")

One actionable notification beats 7 panicky ones.

Failure self-alerts

The shape

What to put in the alert

Don't alert on every transient retry

Don't alert from inside the alert

Alert on the summary, not each item

Failure self-alerts

The shape

What to put in the alert

Don't alert on every transient retry

Don't alert from inside the alert

Alert on the summary, not each item

Failure self-alerts

The shape

What to put in the alert

Don't alert on every transient retry

Don't alert from inside the alert

Alert on the summary, not each item

Sign up to practice

Failure self-alerts

The shape

What to put in the alert

Don't alert on every transient retry

Don't alert from inside the alert

Alert on the summary, not each item

Sign up to practice