Schedule DigitalOcean Functions to Run on a Cron Trigger (2026)

DigitalOcean Functions can be scheduled to run on a cron trigger, but it’s not a built-in feature of the Functions platform itself. You’ll need to use an external scheduling service to invoke your Function.

Let’s see how this works with a simple example. Imagine we have a Function that fetches the current weather for a given city and logs it.

// Functions/weather-fetcher/index.js
exports.main = ({ city }) => {
  // In a real scenario, you'd call a weather API here.
  // For demonstration, we'll just log the city and a mock temperature.
  const temperature = Math.floor(Math.random() * 30) + 5; // Random temp between 5 and 35
  console.log(`Current temperature in ${city}: ${temperature}°C`);
  return { city, temperature };
};

This Function, when invoked with a city parameter, will output the temperature. Now, how do we schedule this?

We’ll use DigitalOcean’s own Cron Jobs service. This is a managed service that allows you to run commands on a schedule. We can use this to trigger a curl command that invokes our DigitalOcean Function.

Here’s the setup:

Deploy your Function: You’d deploy this function to DigitalOcean Functions. Let’s assume it’s deployed and accessible at a URL like https://your-function-slug.your-region.digitaloceanapps.com/api/v1/web/your-app-name/weather-fetcher/main.
Get an API Token: You’ll need a DigitalOcean API token with read permissions to create and manage Cron Jobs. Go to your DigitalOcean control panel -> API -> Tokens/Key. Create a new token.
Create a Cron Job: Navigate to your DigitalOcean control panel -> Cron Jobs. Click "Create Cron Job."
- Schedule: This is where you define your cron expression. For example, to run every hour at the 15-minute mark, you’d use 0 15 * * *.
- Command: This is the crucial part. You’ll use curl to make an HTTP POST request to your Function’s endpoint. The payload will contain the city parameter.
```
curl -X POST \
  -H "Authorization: Bearer YOUR_DIGITALOCEAN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"city": "New York"}' \
  https://your-function-slug.your-region.digitaloceanapps.com/api/v1/web/your-app-name/weather-fetcher/main
```
  Replace YOUR_DIGITALOCEAN_API_TOKEN with your actual token, and adjust the Function URL to match your deployment.
- Region: Choose the region where you want the Cron Job to run.

When the Cron Job executes, it will run the curl command. This curl command sends a POST request to your DigitalOcean Function. The Function then executes, fetches the (mock) weather, logs it, and returns the temperature. The output of the curl command (which is the return value of your Function) will be logged by the Cron Job service.

The most surprising true thing about this setup is that you’re using a separate scheduling service (Cron Jobs) to trigger a serverless compute service (Functions) that’s designed to run on demand. It elegantly bridges the gap between event-driven, on-demand execution and time-based, recurring execution without needing to manage your own scheduler.

The core mechanism at play here is HTTP invocation. DigitalOcean Functions expose HTTP endpoints for web functions. The Cron Job service, when it runs, simply makes an HTTP request to that endpoint, just as any other client would. The Authorization header ensures that only authenticated requests can trigger your Function. The Content-Type: application/json and the -d flag in curl are essential for passing structured data to your Function’s handler.

The mental model to build is one of decoupled services: a scheduler (Cron Jobs) that reliably triggers an executor (Functions) via a standard protocol (HTTP). You control the what (your Function code), the when (the cron schedule), and the how (the curl command with its payload and authentication).

One thing most people don’t know is that the output of your Function’s return statement is what gets sent back as the HTTP response body. If your Function returns a JSON object, curl will capture that JSON. The Cron Job service itself will log this output, making it available for review in the Cron Jobs interface. This is super useful for debugging and observing the results of your scheduled tasks.

The next logical step is to explore how to handle more complex scheduling needs, like running a Function only on weekdays or at specific intervals within a day, using more advanced cron expressions or potentially other external scheduling tools.