docs/daprdocs/content/en/developing-applications/building-blocks/jobs/jobs-features-concepts.md

type	title	linkTitle	weight	description
docs	Features and concepts	Features and concepts	2000	Learn more about the Dapr Jobs features and concepts

Now that you've learned about the [jobs building block]({{< ref jobs-overview.md >}}) at a high level, let's deep dive into the features and concepts included with the Dapr Jobs engine and SDKs. Dapr Jobs:

• Provides a robust and scalable API for scheduling operations to be triggered in the future.
• Exposes several core capabilities which are common across all supported languages. which are common across all supported languages.

Dapr Jobs provide a robust and highly-scalable API for scheduling operations to be triggered in the future.

Job identity

All jobs are registered with a case-sensitive job name. These names are intended to be unique across all services interfacing with the Dapr runtime. The name is used as an identifier when creating and modifying the job as well as to indicate which job a triggered invocation is associated with.

Only one job can be associated with a name at any given time. Any attempt to create a new job using the same name as an existing job will result in an overwrite of this existing job.

Scheduling Jobs

A job can be scheduled using any of the following mechanisms:

• Intervals using Cron expressions, duration values or period expressions
• Specific dates and times

Note that for all time-based schedules, if a timestamp is provided with a timezone via the RFC3339 specification, that timezone will be used instead, but when not provided, the time will be assumed to be the timezone used by the server running Dapr. In other words, do not assume that times will run in UTC unless you've specified this when scheduling the job.

Schedule using a Cron expression

When using a Cron expression to schedule a job to execute on a specific interval, the expression is written using 6 fields spanning the values specified in the table below:

seconds	minutes	hours	day of month	month	day of week
0-59	0-59	0-23	1-31	1-12/jan-dec	0-6/sun-sat

Example 1

"0 30 * * * *" will trigger every hour on the half-hour mark

Example 2

"0 15 3 * * *" will trigger every day at 03:15

Schedule using a duration value

This reflects use of a Go duration string documented here in which a string consists of a possibly signed sequence of decimal numbers, each with an optional fraction and a unit suffix. Valid time units are "ns", "us", "ms", "s", "m" or "h".

Example 1

"2h45m" will trigger every two hours and 45 minutes

Example 2

"37m25s" will trigger every 37 minutes and 25 seconds

Schedule using a period expression

The following period expressions are supported. Note that the "@every" expression also accepts a Go duration string as documented above:

Entry	Description	Equivalent Cron expression
@every	Run every (e.g. "@every 1h30m")	N/A
@yearly (or @annually)	Run once a year, midnight, January 1st	0 0 0 1 1 *
@monthly	Run once a month, midnight, first of month	0 0 0 1 * *
@weekly	Run once a week, midnight on Sunday	0 0 0 * * 0
@daily or @midnight	Run once a day at midnight	0 0 0 * * *
@hourly	Run once an hour at the beginning of the hour	0 0 * * * *

Schedule using a specific date/time

A Job can also be scheduled to run at a particular point in time by providing a date that's specified using the RFC3339 specification.

Example 1

"2025-12-09T16:09:53+00:00" Indicates that the job should be run on December 9, 2025 at 4:09:53 PM UTC.

Scheduled triggers

When a scheduled Dapr Job is triggered, the runtime sends a message back to the service that scheduled the job using either the HTTP or gRPC approach, depending on which is registered with Dapr when the service starts.

gRPC

When a job reaches its scheduled trigger time, the triggered job is sent back to the application via the following callback function:

Note: The following example is in Go but applies to any programming language with gRPC support.

import rtv1 "github.com/dapr/dapr/pkg/proto/runtime/v1"
...
func (s *JobService) OnJobEventAlpha1(ctx context.Context, in *rtv1.JobEventRequest) (*rtv1.JobEventResponse, error) {
    // Handle the triggered job
}

This function processes the triggered jobs within the context of your gRPC server. When you set up the server, ensure that you register the callback server, which will invoke this function when a job is triggered:

...
js := &JobService{}
rtv1.RegisterAppCallbackAlphaServer(server, js)

In this setup, you have full control over how triggered jobs are received and processed, as they are routed directly through this gRPC method.

HTTP

If a gRPC server isn't registered with Dapr when the application starts up, Dapr will instead trigger jobs by making a POST request to the endpoint /job/<job-name>. The body will include the following information about the job:

• Schedule: When the job triggers occur
• RepeatCount: An optional value indicating how often the job should repeat
• DueTime: An optional point in time representing either the one time when the job should execute (if not recurring) or the start join from which the schedule should take effect
• Ttl: An optional value indicating when the job should expire
• Payload: A collection of bytes containing data originally stored when the job was scheduled

The DueTime and Ttl fields will reflect an RC3339 timestamp value reflective of the timezone provided when the job was originally scheduled. If no timezone was provided, these values will indicate the timezone used by the server running Dapr.