Administration → Scheduled tasks (GET /api/v1/tasks) lists what
Warda runs by itself, each with its name and a sentence saying what it
does (0.6.9 adds those of ha.sync: "On the secondary box of a pair:
copies the configuration of the primary every minute.", and of
sites.status: "Every 15 minutes: sends the state of this site (counts
only) to the manager box through the online service."), the last run
(time, duration, error), the next one and whether it is running; by pages
of 50 lines unless chosen otherwise (see Reports):
| Task | When |
|---|---|
Blocklists (lists), and one per sensitive category in use (lists.category.<id>) |
at start, then every hour (WARDA_LIST_REFRESH, with up to 10% jitter): each list asked with its ETag, downloaded only when it changed. The lists themselves are built again by warda-lists every night at 03:17 UTC (see Lists) |
Watch of the cuts (watch.cuts) |
every 2 minutes |
Profiles by age (profiles.ages) |
at start, then every hour |
School holidays (holidays) |
checked daily; the official calendar imported again when older than 7 days |
Sorting of the new devices (devices.classify) |
1 minute after start, then every 10 minutes |
Local names (dns.local_names) |
every minute |
Presence on the network (network.presence) |
every 15 minutes |
Network check (network.checks) |
2 minutes after start, then every 5 minutes; from 0.8.5 each run is recorded (when, how long), and its next run shown from the start |
IPv6 announcements (network.ipv6) |
a router solicitation at start, then every 10 minutes; from 0.8.5 each run is recorded, with the error when the solicitation could not be sent |
Device makers (devices.oui, from 0.8.5) |
10 minutes after start, then once a day: the makers of the hardware addresses from warda-lists (see Network scan) |
Checks of the services (probes) |
90 seconds after start, then every 15 minutes; the last results are kept across restarts |
Network scan (network.scan) |
2 minutes after start, then every night at 03:15 |
Exposure on the Internet (network.exposure, from 0.8.0) |
"Every 7 days": 10 to 60 minutes after the start of a box never checked, then once a week at a slot of its own; a slot missed, 2 to 12 minutes after the start; another router, within the hour; never on the secondary of a pair (see Exposure on the Internet) |
Known data breaches (breaches, from 0.8.0) |
once a week at a minute of its own, the new addresses a minute after they are added; once a day while the service is not open (see Known data breaches) |
Local learning (learning) |
shortly after start, then every hour |
Collective base (collective) |
only when turned on: 2 to 5 minutes after, then every 6 hours (or the delay the online service asks), at most once an hour when decisions or doubts wait; later after a failure |
One device per machine (devices.merge) |
a minute after start, then every 5 minutes: see One device per machine |
Country of the installation (instance.country) |
30 seconds after start while the country came from the time zone, else a week after the last answer; an hour later after a failure; never while an administrator chose the country |
Data loss prevention (business.dlp) |
every day: removes the events older than 90 days |
Security center (business.center) |
10 minutes after start, then every hour, with Warda Business: records the score of the day, forgets those older than 400 days |
Company reports (business.reports) |
3 minutes after start, then every hour, with Warda Business: computes the week and the month and keeps them for their page (see Company reports) |
Users of the directory (business.identity) |
5 minutes after start, then every hour, while an import is on (the directory, and from 0.8.2 Microsoft Entra ID and Google Workspace, each on its own) |
High availability (ha.sync) |
on the secondary of a pair: every minute, the configuration of the primary |
Sites (sites.status) |
in an organisation of sites: every 15 minutes, and at once after joining |
Plan from the customer area (plan) |
1 to 5 minutes after start, then every 24 hours give or take an hour: renews the statement of the plan (see Customer area); from 0.7.9, with the key of the customer area in Warda, on every box that has the online service (it did not run in 0.7.5 to 0.7.8) |
End of the unblocks (business.unblock) |
ends the unblocks approved for a while on time (and those of 15 minutes from the block page), expires the requests left a week without answer |
Alerts watched (alerts.watch, from 0.8.5) |
every 6 hours, only while an alert is kept under watch: tells again, every 14 days, an exposure not acknowledged or a data breach still found (see Alerts) |
Unusual days (reports.anomalies, from 0.8.5) |
15 minutes after start, then every hour, with the trends and the alerts: the last 3 complete days of each device (see Trends and unusual days) |
Summary of the week (reports.weekly, from 0.8.5) |
every hour: from Monday 06:00, keeps the summary of the week that ended, then sends it by e-mail when that is on; the recipients that failed again within the hour, three times at most; never on the secondary of a pair (see Summary of the week) |
Anonymous statistics (telemetry) |
1 to 5 minutes after each start, then once in each half of the UTC day at a random time ("Every 12 hours"); 15 to 30 minutes after a failure, 3 times a half-day at most |
Certificate of the encrypted DNS (certificate) |
10 minutes after start, then every 12 hours: renewed 30 days before its end |
DNSSEC check (dnssec.check) |
a minute after start, then every 6 hours |
Country database (geoip) |
5 minutes after start, then every day |
Retention of the journal (journal.retention) |
1 minute after start, then every hour |
Nightly backup (backup) |
every night at 01:30 (once a backup password is set) |
Updates (updates, Debian package) |
run by the system (warda-update.timer): looks for a new version every 6 hours at minutes of its own, installs it between 02:00 and 05:00 with automatic updates on ("Every 6 hours") |
New versions (updates.check, Docker image and archive) |
1 to 61 minutes after start, then every 6 hours while the check is on ("Every 6 hours"); nothing is installed |
System updates (os.check, Raspberry Pi image) |
6 hours after the last check or installation of the updates of the system (1 to 61 minutes after start on a box never checked): asks root to list them; nothing is installed without an administrator |
Only the tasks that concern the box (from 0.8.5). A task that never
runs as the box is set is left out of the page, instead of saying "Not
yet" for ever: the synchronisation of a pair (ha.sync) on a box that is
not its secondary, the state of a site (sites.status) outside an
organisation, the import of a directory (business.identity) that is not
set, the nightly backup without a backup password, the check of the known
breaches without an address watched, the import of the school holidays
without a region or zone chosen, the exchanges of the collective base
while it is off, the alerts told again while none is kept under watch, the
summary of the week on the secondary of a pair, and the watch of the IPv6
announcements on a machine without IPv6. A setting that cannot be read
keeps the task shown. After the beta, the tasks of a function the plan of
the box does not have are left out too: the school holidays, the known
breaches, the collective base, the alerts watched, the unusual days, the
summary of the week and those of Warda Business (taskFeatures in
internal/admin/tasks.go; function scheduled-tasks of the catalogue).
During the beta every function is open: they show as before.
A run that had nothing to do (no backup password, a scan already running)
is not counted. The times are those of the box; the state is kept in
memory and starts again with Warda. GET /api/v1/tasks gives, for
updates, every_s (21600) and next_run (the next look of this machine)
since 0.7.0, and lists updates.check outside the Debian package.
Background tasks and their rhythm#
The tasks that talk to the online services of Warda, in detail (the delays are spread and jittered so that the boxes never ask together):
| Task | First run | Then | After a failure | Other limits |
|---|---|---|---|---|
Collective base (collective, only when turned on) |
2 to 5 minutes after it is turned on | every 6 hours, or the delay the online service asks (1 hour to 7 days); decisions and doubts waiting go at most once an hour | 5 minutes, then doubled 3 times, up to 6 hours (+20 % jitter); a Retry-After is followed up to 24 hours |
Exchange now: once every 5 minutes; a doubt is sent again at most once a week; an opinion lives 24 hours unless the service says otherwise (30 days at most) |
Certificate of the encrypted DNS (certificate) |
10 minutes after start | every 12 hours | tried again at the next check | renewed less than 30 days before its end, or when its name changes |
Checks of the services (probes) |
90 seconds after start | every 15 minutes | at the next check | the last results kept across restarts |
Anonymous statistics (telemetry) |
1 to 5 minutes after each start | once in each half of the UTC day, at a random time | 15 to 30 minutes later, 3 times a half-day at most | counted once a day by the service |
Updates (updates, Debian package) |
3 minutes after the machine starts (timer) | a look every 6 hours at minutes of its own; the installation once a night, 02:00 to 05:00 | the look waits for the next time; the night tries again every 5 minutes in its window | the installation only with automatic updates on |
New versions (updates.check, Docker, archive) |
1 to 61 minutes after start | every 6 hours | at the next time | only while the check is on |
Country of the installation (instance.country) |
30 seconds after start while the country came from the time zone | a week after the last answer | an hour later | never while an administrator chose the country |
Plan from the customer area (plan, from 0.7.9) |
1 to 5 minutes after start | every 24 hours, give or take an hour | the last statement kept; tried again at the next time | Renew now: once a minute; a statement lives 14 days |
Failover of the online service (failover, from Warda 0.7.7: the failover key is embedded) |
1 to 5 minutes after start | every 6 hours, give or take 30 minutes | at the next time | at once after 3 failures in a row of the online service, at most once an hour |
Exposure on the Internet (network.exposure, from 0.8.0; the check from outside only once the terms are accepted) |
10 to 60 minutes after the start of a box never checked | once a week, at a slot of the week of its own (a hash of the identifier of the installation, never sent); another router (address and hardware address of the gateway, compared every hour) starts one, not within an hour of the last | a result that cannot be written waits an hour | Check now: one at a time, every 2 minutes at most; the service allows 6 checks a day per box and per address, one request per family of addresses |
Known data breaches (breaches, from 0.8.0, with the plan) |
a minute after the first address is added | once a week, at a minute of the week of its own | not open: once a day; limit, busy: the delay asked (10 minutes to 24 hours, else an hour); otherwise an hour, doubled up to 24 hours |
Check now: once a day per address, 30 seconds apart; 20 prefixes a day per box at the service |
| Protection outside the home (the relay, from 0.8.0; not a scheduled task: a connection kept open while it is on) | at once when turned on | pings every 30 seconds | after 1 second, doubled up to 60 seconds with jitter; a Retry-After followed, an hour at most |
one connection per second at most |
The countries come from IP to Country Lite by DB-IP (CC BY 4.0, see
NOTICE): the release build ships the database of the month
(internal/geoip, stage geoip of the Dockerfile) and Warda downloads the
new one each month (download.db-ip.com) into its data directory. Only the
country of the first address of each answer is counted, per day for the
whole network (kept 35 days); the queries keep no address.
Each installation draws a random identifier, WRD-FR-1234-ABCD-EFGH: its
country (see Country of the installation;
ZZ when unknown), four digits and eight characters. It is shown on the dashboard and kept in backups;
nothing of the machine is in it, and it is never sent by Warda. (A check
that no other installation has the same one will come with the online
services.)