> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/analyze-and-tune-workloads/recurring-analyses.md).
# Run recurring analyses
Schedule repeatable analyses like daily health checks or weekly digests.
Have the assistant run the same analysis on a schedule: a daily health check, a weekly performance digest, or a regular post-deployment review. Trends and regressions then surface without manual effort.
**Example prompt:**
* "Every day, summarize yesterday's workload for my prod-eu-1 instance and flag any regressions."
A daily scheduled analysis, with simulated data.
{% hint style="info" %}
**Tip: end the run with a report you can send around.**
Add "...and finish with an interactive HTML report of the analysis" to the prompt. The assistant builds a single self-contained `.html` file from its report template, which your scheduler can attach to an email, drop in a shared folder, or post to a chat channel.
See [Generate and share reports](/manual/ai-connector/use-the-assistant/generate-reports.md) for what the report contains and its Markdown twin.
{% endhint %}
{% content-ref url="/pages/qmENF1FoHzuXVcA6Sfsc" %}
[Generate and share reports](/manual/ai-connector/use-the-assistant/generate-reports.md)
{% endcontent-ref %}
## Schedule it from a desktop app
Most desktop assistants now have a built-in scheduler, so a recurring analysis needs no cron and no script. In most of them you just ask in the chat: describe the analysis and when it should run, as in the example prompt above, and the assistant sets up the schedule.
| Desktop app | Scheduling feature | Where to find it | Where the run executes |
| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------- |
| [Claude desktop app](/manual/ai-connector/connect-a-desktop-app/configure-claude-desktop-windows.md) | Routines: local scheduled tasks and cloud routines | **Code** tab › **Routines** › **New routine**, then **Local** or **Cloud** | **Local**: your machine. **Cloud**: Anthropic's cloud |
| [ChatGPT desktop app](/manual/ai-connector/connect-a-desktop-app/configure-chatgpt-desktop-app.md) | Scheduled tasks | **Scheduled** in the sidebar, or ask in a chat | Your machine |
| [Microsoft Copilot app](/manual/ai-connector/connect-a-desktop-app/configure-microsoft-copilot-app.md) (Cowork) | Scheduled prompts | Ask in a Cowork message, or **Automations** › **Create** | Microsoft's cloud |
| [Google Gemini app](/manual/ai-connector/connect-a-desktop-app/configure-gemini-desktop-app.md) (Gemini Spark) | Schedules | Switch to **Spark** and describe the task, or **Schedules** › **Create manually** | Google's cloud |
Google's [Antigravity 2.0](/manual/ai-connector/connect-a-cli-assistant/configure-antigravity-cli.md#use-the-antigravity-desktop-app) also lists scheduled tasks in its [feature overview](https://antigravity.google/docs/features/).
{% hint style="info" %}
This table follows the vendors' documentation, last checked on 2 October 2026. These features change often, and their availability depends on your plan and your organization's settings.
{% endhint %}
Where the run executes decides what it needs:
* **On your machine.** The run uses the Datasentinel MCP server and Skill configured in the app, so a platform on a private network stays reachable. The computer must be on and the app running at the scheduled time. The Claude desktop app starts one catch-up run when it wakes up after a missed time.
* **In the vendor's cloud.** The run works while your computer is off. It uses the connector, plugin or custom app attached to your account, and the platform must be reachable from the vendor's cloud. See [MCP servers on a private network](/manual/ai-connector/troubleshooting/private-network-mcp-servers.md).
A few points to check before you rely on a schedule:
* **Approvals.** Nobody is there to approve a tool call, so a run that asks for one waits or stops. Start the first run by hand and approve the Datasentinel tools for good: **Run now** and "always allow" in the Claude desktop app, **Activate and run now** in Cowork, the server's approval mode in the [ChatGPT desktop app](/manual/ai-connector/connect-a-desktop-app/configure-chatgpt-desktop-app.md#approve-the-datasentinel-tools). The Datasentinel tools only read monitoring data, so allowing them is safe.
* **The Skill.** Check on that first run that the answer follows the Datasentinel Skill. If it does not, name it in the scheduled prompt: "Use the datasentinel skill to...".
* **Limits.** Cowork allows up to 25 scheduled prompts. A Claude cloud routine runs at most once an hour. Gemini Spark schedules need a Google AI Pro or Ultra subscription and a personal account, and Google does not offer them in the European Economic Area, Switzerland, the United Kingdom or Nigeria.
* **The result.** Ask for an HTML report at the end of the prompt, as in the tip above, and say where it should go.
Vendor documentation: Anthropic's [Schedule recurring tasks in Claude Code Desktop](https://code.claude.com/docs/en/desktop-scheduled-tasks) and [Automate work with routines](https://code.claude.com/docs/en/routines), OpenAI's [Scheduled tasks](https://learn.chatgpt.com/docs/automations), Microsoft's [Schedule prompts](https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/use-cowork#schedule-prompts), and Google's [Create & manage schedules for tasks in Gemini Spark](https://support.google.com/gemini/answer/17094710).
## Authentication in a scheduled run
The Datasentinel MCP server is protected by OAuth: you sign in once, and the assistant keeps the session alive. A scheduled run uses that same session, as long as one exists where the run executes. A user token is needed only where nobody can sign in. See [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md).
| Who runs the prompt | How it authenticates | What you set up |
| ----------------------------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| The assistant's own scheduler, on your machine | The OAuth session the assistant holds on that machine | Nothing more: you already signed in |
| The assistant's own scheduler, in the vendor's cloud | The OAuth session of the connector you added to your account | Sign in on the connector. The platform must be reachable from the vendor's cloud |
| A CLI assistant started by cron or another job scheduler | The OAuth session stored on that host | Sign in once on that host, under the account that runs the job |
| A script, a Python agent or a CI pipeline, with no stored session | A user token, sent as a header | Renew the token every 24 hours |
{% hint style="info" %}
**Run at least every ten days.** The OAuth session renews itself as long as the assistant uses the server at least every ten days, so a daily or weekly job never signs in again. A job that fires less often finds the session expired: sign in again before it runs, or use a user token. An administrator can also end a session at any time.
{% endhint %}
### With the assistant's own scheduler
The schedulers listed in [Schedule it from a desktop app](#schedule-it-from-a-desktop-app) need no token. Where the scheduler runs decides which session it uses.
* **On your machine.** The run uses the MCP servers and the session of that machine. With Claude, this is a local scheduled task of the Claude desktop app, or `/loop` in a Claude Code session. A `/loop` task only fires while the session is running, and expires after seven days.
* **In the vendor's cloud.** The run only sees the servers attached to your account there, and signs in through them. With Claude, a cloud routine (`/schedule`, or [claude.ai/code/routines](https://claude.ai/code/routines)) uses your claude.ai **connectors**. A server added with `claude mcp add` is stored on your machine and is not available to it. Add the Datasentinel server as a connector and sign in on it. A routine also loads its Skills from the repository it clones, so the Datasentinel Skill has to be committed there.
See Anthropic's [Run prompts on a schedule](https://code.claude.com/docs/en/scheduled-tasks) and [Automate work with routines](https://code.claude.com/docs/en/routines).
### With cron and a CLI assistant
A CLI assistant started by cron reuses the OAuth session stored on the host. No token is involved. Register the server and sign in once, under the account that will run the job:
```bash
claude mcp add --scope user --transport http datasentinel-production https:///mcp
claude mcp login datasentinel-production --no-browser
```
The second command prints the sign-in link, for a host without a browser. See [Sign in from a server without a browser](/manual/ai-connector/server-setup/how-authentication-works.md#sign-in-from-a-server-without-a-browser).
The cron entry then holds only the analysis:
```bash
# every day at 06:00
0 6 * * * claude -p "Summarize yesterday's workload for prod-eu-1 and flag any regressions"
```
A few rules for an unattended run:
* **Same account.** The session is stored for the operating system account that signed in, in a credentials file or in the system keychain. The job must run under that account and be able to read that store.
* **No sign-in during the run.** A non-interactive run cannot open the login page. If the session has expired or was ended, the run reports that the server needs a sign-in instead of an analysis. Sign in again with `claude mcp login`, and watch the job's output.
* **No approval prompt either.** Allow the Datasentinel tools beforehand, as described in [Approve the Datasentinel tools](/manual/ai-connector/connect-a-cli-assistant/configure-claude-code.md#approve-the-datasentinel-tools).
* **Test it once.** Run the exact command from the scheduler before you rely on it.
Other CLI assistants work the same way when their non-interactive mode reads the stored session. Each assistant's page in this section gives its sign-in command.
### With a user token
A script, a Python agent or a CI pipeline on a fresh runner has no stored session, and nobody to sign in. It authenticates with your Datasentinel [user token](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/implementation/platform-usage/api-reference/access-token), sent as an `Authorization: Bearer` header by the MCP client. The platform issues these tokens with a **24-hour lifetime** and does not renew them, so the token must be stored where the run can read it, and renewed before it expires.
A server registered with a header never opens the login page: it uses the token only. Choose one method per registered server.
#### Configure the token as a header
The token goes in the client's configuration, never in the prompt: the assistant does not read a token from the conversation. With Claude Code, register the server with the header and read the value from the cache file:
```bash
claude mcp add --scope user --transport http datasentinel-production https:///mcp \
--header "Authorization: Bearer $(cat ~/.datasentinel_token)"
```
Other clients have the same option under another name (`bearer_token_env_var` in Codex, `headers` in a Python agent); each assistant's page in this section gives it. The scheduled prompt then contains only the analysis.
**The client reads the token when it is configured or started, not at each call.** In the command above, the shell substitutes the file's content once, at registration, so the registered header keeps that value until you register again. A client that reads an environment variable (Codex) captures it when the process starts. So every scheduled run has to read the current token back after the renewal step and hand it to the client for that run: re-run the registration command, export the variable, or, in a Python agent, read the file at start-up as the worked example does.
#### Store the token safely
* Keep the token in its own file (for example `~/.datasentinel_token`) with permissions `0600`, readable only by the account that runs the scheduled analysis.
* Never hard-code the token in a scheduled prompt, in a script, or in a repository: it grants your platform rights to whoever reads it.
* Keep the credentials used for renewal (`DATASENTINEL_USER` / `DATASENTINEL_PASSWORD`) in environment variables or your scheduler's secret store, never in the script itself.
#### Renew the token automatically
The Developers section provides `refresh_token.py`, a standalone script that keeps the cached token in `~/.datasentinel_token` permanently valid: it checks the expiry inside the JWT and mints a fresh token whenever the cached one is missing or about to expire. Run it at the start of each scheduled analysis, then read the token back before the client starts, so the run uses the value the script just wrote. A cron entry for Claude Code looks like this:
```bash
# every day at 06:00: renew the token, re-register the header with the current value, run the analysis
0 6 * * * python3 /opt/datasentinel/refresh_token.py >/dev/null && \
claude mcp add --scope user --transport http datasentinel-production https:///mcp \
--header "Authorization: Bearer $(cat ~/.datasentinel_token)" && \
claude -p "Summarize yesterday's workload for prod-eu-1 and flag any regressions"
```
Running the refresh script on its own schedule instead, shorter than the 24-hour lifetime, works only if the client is also re-registered or restarted after each renewal; otherwise it keeps the previous token.
{% content-ref url="/pages/tYYPnYXT7D6UVZO3k9HD" %}
[Refresh the user token automatically](/manual/ai-connector/developers/refresh-user-token.md)
{% endcontent-ref %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.datasentinel.io/manual/ai-connector/analyze-and-tune-workloads/recurring-analyses.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
