Panels uses a reactive execution model — when an upstream node changes, all downstream dependents re-execute automatically. This page explains how execution plans work, how caching prevents unnecessary reruns, and how scheduling controls when nodes run.
TODO: This page needs full content.

​
Execution plans

When a node is triggered (manually or by a schedule), Panels builds an execution plan — the minimal subgraph of stale nodes that need to run.

​
Trigger types

  • Manual — run on demand from the UI or API
  • Scheduled — cron-based recurring execution
  • On change — automatic re-execution when upstream outputs change
  • Webhook — triggered by an external HTTP request
  • API — triggered programmatically via the REST API

​
Caching and fingerprints

Each node run produces a fingerprint based on its inputs and code. If the fingerprint hasn’t changed since the last successful run, the node is skipped.

​
Run statuses

Nodes progress through statuses: pending → running → succeeded / failed / skipped / cancelled.