Scheduled tasks

Some work gets done without any action on your part: conversations are deleted once your retention period has passed, website sources are refreshed, reminders for confirmed appointments are queued, connected shops are synced and the weekly report is prepared. Eight recurring runs with fixed start times take care of this. Here you can see when each run starts, what it does and what it leaves out, and how a run that fails or does not start at all gets noticed.

The runs at a glance

Each run has a name under which it reports and shows up in the Operations area, along with a heartbeat deadline: the maximum time its last run may lie in the past before the run is treated as overdue. While the previous pass of a run is still working, the same run does not start again, so two passes of the same run do not overlap.

Time and time zone

The application keeps its clock in UTC, so every start time on this page is a UTC time. To get German local time, add two hours during summer time (CEST) and one hour in winter (CET). Hourly runs stay at the same minute past the hour.

Two runs also work with local time. The weekly report fixes the start of the week in Europe/Berlin, and the appointment reminder states the appointment time in the time zone that applies to your appointments.

Each run in detail

Conversation pruning

Every day at 03:17 UTC this run deletes conversations that are older than the period you set under Retention periods. It works per tenant and per channel:

• All conversations covers conversations from the chat window on your website.
• Test conversations covers your tests. Without a value of its own, the period for all conversations applies.
• Via the API covers conversations held through the API. Here too, the period for all conversations applies if no separate value is set.

If no period is set, nothing is deleted, and the setting reads Nothing is deleted. A period can be set to anything from 1 to 3650 days. What counts is the moment the conversation was created. For each tenant, deletion happens in batches of 200 conversations across all channels. Before a batch is deleted, a line is added to the activity log reading Retention period applied together with the number of deleted conversations per channel. Usually that means one line per tenant and run; only more than 200 expired conversations produce several. A run without deletions leaves no line. If the line cannot be written, the batch is not deleted, and the remaining expired conversations of that tenant stay until the next run. The run carries on with the other tenants, but then ends as failed and raises the notice “Lauf '…' fehlgeschlagen”, see Heartbeats and notices. The setting itself is covered under Retention periods.

Refreshing website sources

Every day at 04:23 UTC this run looks after your website sources. It does not fetch any pages itself; it queues jobs that are then processed in the background. It proceeds in three steps.

1. 1

   Step 1

   Mark outdated sources

   A website source in the indexed or new state whose last confirmation lies further back than twice its refresh interval, and at least 14 days, is set to outdated. The last confirmation is the most recent check or, for a source that has not been checked yet, the moment it was added.

2. 2

   Step 2

   Queue the sources that are due

   A website source is due if it has an address that can be fetched, its last confirmation is older than its refresh interval, and its state is indexed, not indexed, outdated or new. A source that failed or became outdated is therefore fetched again. The sources confirmed longest ago go first, with no more than 200 per run. A source that already has an intake or a refresh waiting or running is skipped. These jobs run at priority 7.

3. 3

   Step 3

   Update the search index

   For every tenant with queued sources, one further job prepares the new sections for search. It has priority 8, so it comes after the refresh jobs of the same run.

If more sources are due than the limit of 200 allows, a notice titled “Auffrischung gedeckelt” (warning) is raised for operations, and the remaining sources stay due. You set the refresh interval per source under Refresh interval in days. Values from 1 to 365 days are accepted, for website sources only: A refresh interval exists for website sources only. See Refreshing for details.

Measuring the probe set

Every day at 05:07 UTC this run measures, per tenant, how accurately knowledge search finds its answers. It deliberately starts after the refresh, since measuring a half-ingested collection would show a drop that is not real. Only tenants with a probe set are measured. A tenant without probe lines gets no measurement at all, rather than a score of 0.

Maintenance

Every hour at minute 09 UTC this run tidies up operations and reports anything unusual. It works through the following sections:

• Recovery: background jobs that were left behind unfinished are taken back. See Stuck jobs.
• Finished jobs: completed and failed jobs that ended more than 14 days ago are deleted.
• Abandoned jobs: a pending or running job older than seven days is ended as failed without being carried out, and the notice “Aufträge nach 7 Tagen abgelaufen” (warning) is raised. An email whose delivery job expires this way is recorded as failed, as is an acceptance check run or a setup run whose job expires this way. From completed and failed jobs, recipients and content still held in the job data are removed.
• Stuck sources: a knowledge source that has shown processing for more than two hours without an open job for it and without a setup run reading it is set to not indexed with the reason ingest_failed. This ends, for example, a build whose process crashed. No new run is queued for it.
• Expired access: expired access tokens, password reset tokens past their validity (60 minutes by default), unconfirmed email verifications that have expired, and sessions idle for longer than their lifetime.
• Cache: entries and locks of the database cache whose expiry time has been reached are deleted.
• Probe leftovers: probe rows from the health check that are older than an hour are deleted.
• Retention: further sections deal with logs, enquiries, cases and files. Which of these are deleted and when is described under Retention and deletion.
• Checks: for each lane it compares the retry interval with the longest measured job and reports any lane whose first interval is shorter (warning). If a table is missing from the database schema, it reports “Schema unvollständig” (critical).
• Overdue runs: finally it checks every heartbeat, see Heartbeats and notices.

If one of the clean-up sections fails, the run raises “Aufräumen '…' fehlgeschlagen” naming that section (warning), and the other sections carry on. Rows are deleted in batches of 1000. Where maintenance deletes data after a retention period set for your account, a line reading Retention period applied is added to the activity log for each batch before it is deleted. If that line cannot be written, the batch is not deleted, and the rest of that kind of data in your account stays until the next run. The section carries on with the other accounts and raises the same notice at the end.

Appointment reminders

Every hour at minute 23 UTC this run queues a reminder email for each confirmed appointment starting within the next 24 hours. Once an appointment has begun, no reminder is sent for it. The run is hourly because an appointment can also move into this window through a late confirmation or a rescheduling. An appointment is skipped

• if the account it belongs to is not active,
• if no email address is stored with it,
• if a reminder has already been written for it and its current start. A failed attempt counts too, so no second reminder follows. If the appointment is rescheduled in the conversation and confirmed again by the business, it gets a reminder for the new start, even if it was moved back to the same time.

If the conversation in which the appointment was requested was in English, the email is sent in English; otherwise, including when there is no conversation or it no longer exists, in German. It addresses the recipient by the name recorded with the appointment. It gives the name of your account as the business, the start with date, time and time zone and, where recorded, the appointment type, duration and topic, and the lead time of 24 hours. If the appointment no longer suits, it asks the recipient to cancel in good time: in the chat conversation in which it was requested, or directly with the business. If the appointment belongs to no conversation or the conversation no longer exists, for example because it was deleted once your retention period had passed, it names only the business. The email is not meant to be answered. The time zone comes from the Time zone of the windows setting of your appointment tools. The email gives it as spelled in the time zone database, for example Europe/Vienna, even if europe/vienna was entered. Names that differ only in upper and lower case count as the same zone. If there is no appointment tool, or several of them use different zones, Europe/Berlin applies. Reminders run at priority 5. If one appointment cannot be queued, the others still go ahead, but the run is then marked as failed. How the confirmation itself is produced is explained under Confirmation email.

Shop sync

Every hour at minute 41 UTC this run queues one sync for each tenant with a shop connection switched on (Sync and live re-reading switched on). The actual sync is carried out by the background job. A tenant is skipped

• if its account is not active,
• if its plan does not include a shop connection; in that case operations also receives the notice “Shopanbindung ohne passendes Paket”,
• if a sync for it is already pending or running.

The scheduled sync runs at priority 7. A manual sync started with Sync now has priority 5 and is therefore handled first; if a sync is already open, no second one is queued. A sync has at most 300 seconds in total; after that it stops with sync_timeout. More under Sync, and on job ordering under Order.

Weekly report

On Mondays at 06:41 UTC this run decides who receives a weekly report this week and queues one job for each of them at priority 7. It does not compile anything itself. An account is skipped

• if it is not active,
• if Receive the weekly report is switched off; without a setting of its own, the report is switched on,
• if a report has already been queued or sent for it this week. The week starts on Monday at 00:00 in Europe/Berlin.

The report covers the past seven days with up to five topics and five gaps. It is sent to the account owner, and only to the owner's confirmed address; without one, or after unsubscribing, nothing is sent. See Weekly report and When no report is sent.

Backup

The daily backup is started by the same schedule and reports the same kind of heartbeat as the other runs. It starts at 02:47 UTC by default. The start time and the heartbeat deadline (30 hours by default) can be configured by the platform operators.

What the backup contains, what is deliberately left out and how long backups are kept is covered under The daily backup.

Heartbeats and notices

When a run ends, it leaves a heartbeat under its name. This records the time of the last run, the time of the last success, the outcome, the number of runs and the number of failures. A failure leaves the last success untouched, which shows how long a run has been going wrong. An entry only comes into being with the first heartbeat: a run that has not completed a first pass appears neither in the overview nor in the check for overdue runs. Besides the runs on this page, background processing also reports a heartbeat at regular intervals. If a heartbeat cannot be written, the run carries on regardless.

A failure is reported straight away rather than once the deadline has passed. Whether a run is overdue is checked by the hourly maintenance run. Notices sharing the same key are grouped: when the problem recurs, the existing notice increments its counter and is marked as unseen again. The available severities are info, warning and critical.

What the Operations area shows

In the Operations area, the Recurring runs section lists every run with the columns Name, Last run, Last success, Deadline (in seconds) and State. If no run has checked in so far, it shows No run has reported yet. The state is determined in this order:

• Overdue if the last run lies further back than the deadline,
• otherwise Last run failed if the most recent run went wrong,
• otherwise Operational.

Frequent questions