Crons and platform jobs

Nistor's own maintenance (incident sweeps, alert digests, AI janitors, external-run polls) has three possible drivers. Each job should have exactly one of them armed:

• Cloud Scheduler HTTP crons. Terraform creates a Cloud Scheduler job that calls a backend route on a schedule. The backend module creates these while its enable_legacy_platform_crons input is true (the default; the reference composition deployments/gcp does not set it), each also behind its own enable_* input.
• In-process tick pollers. A service runs the job itself every <NAME>_INTERVAL_SECONDS seconds (0 disables it). A poller marked as replacing a legacy cron stays off on a host whose NISTOR_LEGACY_PLATFORM_CRONS environment variable is true, 1 or yes.
• Platform-job rules. An ordinary scheduling rule fires a nistor_job action that runs a job registered with @platform_job on the backend or jobs service (POST /api/v1/platform-jobs/{job}/run). See the scheduling concepts and the platform_jobs plugin's README.

The scheduler service's own per-minute ticks (on-hold-actions, check-actions-status, cron-on-hold-check) are Cloud Scheduler jobs that nothing else can start: they are always created and are not part of this page's switches.

What runs on a fresh deployment#

A fresh deployment of the reference composition installs no platform-job rules, so every job below runs on its HTTP cron, or not at all when that cron is off by default.

The @platform_job rules (incident_aging_check, incident_orphan_sweep, incident_snooze_recompute, data_trust_weekly_digest, alert_digest_flush, workspace_renew_subscriptions) are not seeded at install: the HTTP crons above drive those jobs until a rules file names them.

Batched alerts need one drain#

alert_batch_drain delivers batched (non-critical) alerts. Both of its drivers are off by default: the backend module's enable_alert_batch_drain input is false and the backend's ALERT_BATCH_DRAIN_INTERVAL_SECONDS is 0. Until one of them is on, those alerts are queued in the alert history and never sent. Critical alerts are not batched and are not affected.

Turn on exactly one driver. Two drains running together post the same Google Chat card twice. The first run flushes the whole backlog queued so far, one card per batch window, so plan it.

• Poller (reference composition): set ALERT_BATCH_DRAIN_INTERVAL_SECONDS (for example 300) for the backend through role_extra_env_vars, and leave NISTOR_LEGACY_PLATFORM_CRONS unset on the backend.
• HTTP cron (a composition that calls the backend module itself): set the module's enable_alert_batch_drain to true, with enable_legacy_platform_crons left true, and leave the interval at 0.

Moving a job to a platform-job rule#

1. Add a rule whose action is nistor_job with the job's name to the environment's rules and sync it with nistor rules sync (the example deployment repository's ci/config-sync.sh syncs envs/<env>/config/rules/).
2. Watch the rule fire in the action runs.
3. Turn the job's HTTP cron off: its own enable_* input, or, once every job has its rule, the backend module's enable_legacy_platform_crons = false, which removes all of its crons in one apply.

The NISTOR_LEGACY_PLATFORM_CRONS switch#

The reference composition does not set it. On a host where it is true, the pollers marked as replacing a legacy cron do not start. Only alert_batch_drain (backend) carries that mark, because only it still has a Cloud Scheduler cron: the switch hands it to that cron. dataform_external_sync, mstr_external_run_poll, slot_poll and mstr_activity_poll lost their crons, so they are not marked and keep running whatever the switch says.