Schedulers are deceptively simple.

You define a function, schedule it to run every N seconds, and move on.

Until configuration changes. Until logic evolves. Until production behaves differently than expected.

This post explains a subtle but common pitfall in Python schedulers and a safe pattern to avoid it.

---

The tempting mistake: binding logic once

When using an interval scheduler (APScheduler, asyncio loops, background tasks), it’s natural to write something like this:

config = load_config()  # runs once at startup

def task():
    do_something(config)

It works. It’s clean. It’s also stale by design.

The scheduler keeps calling task(), but config never changes.

If configuration, feature flags, routing rules, or thresholds evolve at runtime, your scheduled task doesn’t notice.

The system looks dynamic. The behavior isn’t ;)

---

Why this is dangerous in real systems

This pattern becomes risky when:

• configuration is stored in a database
• values are updated without restarts
• logic is meant to evolve dynamically
• the service is long-running (days or weeks)

You end up debugging issues that look like:

• “Why didn’t the task pick up the new value?”
• “Why does it work after a restart?”
• “Why is production behaving differently than staging?”

The scheduler isn’t broken. The design is.

---

The worst mistake: dynamic code execution

Some teams try to “fix” staleness like this:

def task():
    exec(get_logic_from_db())

This does reload logic dynamically.

It also:

• bypasses static analysis
• breaks observability
• introduces security risk
• makes failures unpredictable

exec() solves freshness by sacrificing safety.

This trade-off is almost never worth it.

---

The correct mental model

A scheduled task should be:

• stable in structure
• dynamic in behavior

The task itself should not change. What it calls can or should to be precise.

---

The safe pattern: late binding via callables

Instead of binding data or logic (potentially change in runtime) at startup, fetch what you need at execution time.

Move dynamic resolution inside the task.

Step 1: define safe callables

def send_alert():
    ...

def recheck_config():
    ...

function_registry = {
    "send_alert": send_alert,
    "recheck_config": recheck_config,
}

This gives you:

• explicit allowed behavior
• static analysis support
• predictable execution paths

---

Step 2: resolve logic per execution

def task():
    fn = function_registry.get("send_alert")
    if callable(fn):
        fn()

Now:

• logic is resolved at runtime
• updates take effect immediately
• no restart required
• no dynamic code execution

The scheduler stays dumb. The system stays flexible.

---

Dynamic configuration the right way

The same principle applies to configuration.

Instead of this:

config = load_config()

def task():
    do_something(config)

Do this:

def task():
    config = load_config()
    do_something(config)

Yes, it’s slightly more work per execution.

That cost is usually trivial compared to:

• correctness
• clarity
• predictability

---

Async services make this even more important

In async services (FastAPI, background workers, schedulers):

• tasks may live for a long time
• restarts are less frequent
• multiple concerns share the same process

Stale state becomes harder to detect.

A scheduler that looks dynamic but isn’t can silently violate assumptions for hours or days.

Async systems reward explicitness.

---

When this pattern matters most

This approach is especially important when:

• tasks depend on database-driven config
• feature flags control behavior
• operational thresholds change frequently
• scheduled jobs affect external systems

In other words: production.

---

What not to overdo

This doesn’t mean everything must be dynamic.

Avoid:

• reloading heavy dependencies every run
• rebuilding large objects unnecessarily
• hiding complexity behind indirection

Dynamic resolution should be targeted, not global.

---

The takeaway

If a scheduled task depends on logic or configuration that can change:

• don’t bind it once at startup
• don’t execute arbitrary code
• resolve behavior explicitly, per execution

A simple rule of thumb:

• Tasks should be stable.
• Behavior should be reloadable.

Designing this way costs little and saves you from subtle, production-only bugs.

---