# Orchestrator Settings

The following settings are available in the Orchestrator config (backend/config/config.ini):

<table data-header-hidden><thead><tr><th width="69"></th><th width="134"></th><th width="159"></th><th width="126"></th><th width="110"></th><th></th></tr></thead><tbody><tr><td><strong>No</strong></td><td><strong>Parameter</strong></td><td><strong>Description</strong></td><td><strong>Default Value</strong></td><td><strong>Value Range</strong></td><td><strong>Recommendations</strong></td></tr><tr><td>1.</td><td>store_logs<br>_days</td><td>The number of days for which Robot Logs are stored in the main database. After the specified number of days, the Logs will be moved to the archive database and deleted from the main database.</td><td>180</td><td>from 0<br>to 180</td><td><em>Note that when selecting a value of 0, Logs are stored indefinitely.</em></td></tr><tr><td>2.</td><td>store_audit<br>_days</td><td>The number of days for which Audit Records, which log actions and changes in the system, are stored in the main database. After the specified period, Audit Records are permanently deleted from the main database.</td><td>180</td><td>from 0<br>to 180</td><td><em>Note that when selecting a value of 0, Audit Records are stored indefinitely.</em></td></tr><tr><td>3.</td><td>store_errors<br>_days</td><td>The number of days for which records of system errors are stored in the system_errors table. After the specified period, system errors are permanently deleted from the main database.</td><td>30</td><td>from 0<br>to 180</td><td><em>Note that when selecting a value of 0, records of System errors are stored indefinitely.</em></td></tr><tr><td>4.</td><td>store_tasks<br>_days</td><td>The number of days for which records of Tasks are stored in the main database. After the specified number of days, Tasks will be moved to the archive database and deleted from the main database.</td><td>0</td><td>from 0<br>to 180</td><td><em>Note that when selecting a value of 0, records of Tasks are stored indefinitely.</em></td></tr><tr><td>5.</td><td>store_jobs<br>_days</td><td>The number of days for which records of Jobs are stored in the main database. After the specified number of days, Jobs will be moved to the archive database and deleted from the main database.</td><td>0</td><td>from 0<br>to 180</td><td><em>Note that when selecting a value of 0, records of Jobs are stored indefinitely.</em></td></tr><tr><td>6.</td><td>clean_time</td><td>The time when the script for archiving and deleting records is triggered. It is set in the format HHMM, where HH is hours and MM is minutes. This time is set in the UTC+0 (Greenwich) time zone, allowing for precise determination of the script activation moment.</td><td>0000</td><td><p>from 0000</p><p>to 2359</p></td><td><em>The choice of time for cleanup runs should be based on an analysis of system load to minimize performance impact. For example, 0200 means that data unloading will occur at 2:00 AM (UTC+0).</em></td></tr><tr><td>7.</td><td>show_license<br>_exp_modal</td><td>Provides the option to disable notifications about expiring licenses when logging into the system.</td><td>1</td><td>1 or 0</td><td><em>Note that a value of 1 activates the message display, while 0 disables this message.</em></td></tr><tr><td>8.</td><td>max_tasks<br>_to_view</td><td>Defines the maximum number of Tasks that can be displayed simultaneously on the Tasks panel.</td><td>30000</td><td>from 0 to ∞</td><td><em>Note that when selecting a value, all records on the Tasks panel are sorted by date in descending order.</em></td></tr><tr><td>9.</td><td>mail_check<br>_interval</td><td>Defines the interval in minutes for how often the Orchestrator will check the mail server for new emails when processing Triggers. This setting applies to Triggers that work with mail.</td><td>10</td><td>from 1 to ∞</td><td><em>It is recommended to set a value that ensures an optimal frequency of receiving new emails from the server while avoiding excessive load from frequent requests.</em></td></tr><tr><td>10.</td><td>mail_check<br>_timeout</td><td>Defines the interval in seconds for how long the system will wait for a response from the mail server before issuing an error. This setting applies to Triggers that work with mail.</td><td>10</td><td>from 1 to ∞</td><td><em>It is recommended to choose a value that provides sufficient time to receive a response from the server while minimizing delays in the workflow.</em></td></tr><tr><td>11.</td><td>cron_task<br>_abandoned<br>_interval</td><td>The number of hours after which the Orchestrator will mark started (in progress) but not completed Tasks as Abandoned.</td><td>24</td><td>from 1 to ∞</td><td><em>It is important to analyze the average task execution time to determine the optimal interval.</em></td></tr><tr><td>12.</td><td>cron_job<br>_failed<br>_interval</td><td>The number of hours during which the system waits for the successful completion of a Job. After the specified time, if the Job has not been successfully completed, it automatically receives a status of "Failed".</td><td>24</td><td>from 1 to ∞</td><td><em>It is important to analyze the average job execution time to determine the optimal interval.</em></td></tr><tr><td>13.</td><td>show_<br>process_only_for<br>_users_in<br>_assistant</td><td>This parameter provides the option to display the list of available Processes in Sherpa Assistant only after authenticating on behalf of the User.</td><td>0</td><td>0 or 1</td><td><em>Note that when setting the value to '1', the list of Processes will be displayed immediately after logging into the Assistant. If the value is set to '0' (default), the list of Processes will not be visible until authentication on behalf of a specific user is completed. In this case, only those Processes that are available to this user will be displayed in the list.</em><br><br><em>This parameter should be enabled when using the Access Folder system to restrict the Processes available to users.</em></td></tr></tbody></table>

\ <br>

\ <br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sherparpa.ru/en/sherpa-rpa/sherpa-orchestrator/rabota-v-sherpa-orchestrator/nachalo-raboty-v-sherpa-orchestrator/nastroiki-orkestratora.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.