/polling is the single place to see every recurring background operation that keeps the control plane and its agents in sync — how often each one runs, when it last ran, when it runs next, and why it last failed.
Almost everything on the dashboard that appears to update on its own is driven by one of these operations. When a codebase looks stale, a build never starts, or a GitHub or GitLab notification never arrives, this page tells you whether the responsible loop is running, disabled, or erroring.
Using the page
The page has two cards. Server operations are loops running inside the server process. Agent operations are loops running on each enrolled machine — one row per agent per operation, with the agent name linking to its agent detail page.
The table streams — a subscription pushes changes as operations start and finish, so rows update without a reload. Refresh re-queries everything if you would rather force it.
Statuses
A Stale row is not always a problem. Agent operations report the last time an agent said something, so an offline Mac turns all of its rows stale at once. Check the agent’s connection state first, then the individual operation.
Server operations
These loops live in the server process and start with it.
GitHub actions notifications is the one to read closely, because its Details column reports a mode rather than a plain on or off:
Its interval comes from the GitHub settings rather than from this page. Auto-retry is scheduled at its configured cadence but never runs faster than every 30 seconds.
GitLab follows the same webhook-first model independently. A configured project hook supplies merge-request, pipeline, and job events. Polling remains scheduled as a fallback and shares neither state nor retry counters with GitHub.
Agent operations
Each enrolled agent contributes five rows. Their cadences come from the per-agent overrides on the agent detail page, falling back to the defaults below — and for scan and fetch, to the global values in Codebases.Reading a failure
Check the runtime
A failing server operation affects everyone. A failing agent operation affects only that machine — and if every row for one agent is stale, the problem is the connection, not the operations.
Read the error under the status
Errors are recorded verbatim from the failed pass. Git fetch is the exception: it summarizes as N repositories have fetch errors, and the per-repository reason lives on the codebase detail page.
Compare last completed against cadence
An operation with a recent Last started and no matching Last completed is stuck mid-pass, not idle. The duration on the previous pass tells you what normal looks like.
Fix it where it is configured
Nothing on this page is editable. Cadences live on the agent detail and Codebases pages; whether an operation is enabled follows the feature’s own configuration in Settings.
Notes
- This page is read-only diagnostics. Every cadence and toggle it displays is configured elsewhere.
- Server operation history is kept in memory, so restarting the server clears last-run times and errors until each loop completes its first pass.
- Agent operation rows are derived from stored agent state rather than from a live probe, so they stay visible — and go stale — while an agent is offline.
- Operations appear only once their owning service has started; a feature that has never been configured may register nothing at all.
Related pages
Agents
Connection state and the per-agent interval overrides these rows use.
Codebases
The global scan and fetch intervals behind the agent rows.