Currently, you can only schedule jobs based on a fixed time offset from GMT. This means the actual local time when the job runs will change one hour forward or backward, in spring and fall when daylight savings change.

Add the ability to customize the timeout interval through the Azure portal.
This feature is right now only available through API.

Having the possibility to use date variables in azure scheduler POST requests would allow us for example to make a REST call to azure table storage like 'delete all records before {DateTime.UtcNow.AddMonths(-1)}'.

Maybe this feature exists already, but I can't see it...

It would be great to be alerted via email if any of my HTTP/S jobs fail.

This could be DNS resolution failure, or a response with a code of 4xx or 5xx.

For example when you have created your scheduler job and you click run once. You have no idea after that what's going on with the job and if for example you have made a error in your code and it's just looping endlessly you can't terminate and you are required to wait until the timeout.

We would like an option to prevent the scheduler from wrapping the message with StorageQueueMessage XML. There is no indication in the portal that Azure will alter our message text.

We insert into our queues from the scheduler and our own code. Our messages are JSON strings. It's very inconvenient and inefficient to have to serialize and deserialize multiple times to get/put our message.

When we create a job, we can enter a UTC offset field.
However, when we edit the job, the UTC setting is never saved and start-time and end-time fields are changed as UTC time, as if UTC settings were ignored.

From the perspective of UX, UTC settings should be saved just as we enter the data. This specification may confuse Azure Scheduler users.

Start-time field and End-time field now show 12-hour time; For example, '12:00:00 AM' or in Japanese locale, '12:00:00 午前'. However, we must type Chinese characters '午前' to input a date.
In order to save trouble, it will be useful to show 24-hour time in those fields.

I think that it could be useful to make http call to internal endpoind of "private" cloud services or vm inside a private azure vnet (not externally visible)

Crontab is a widely used anc concise scheduling format. There are numerous open source libraries for a variety of languages available for parsing the format already written.

This is more relevant for jobs that post messages to a queue.
If you think about this scenario, this job is not the "real" job. It only sends a signal to the queue which then has to be processed somewhere else.

In this case, I don't want this single one-time completed job to stay in the collection and account towards my quota. I would like it to be automatically deleted if everything was ok.

Scheduled jobs should expose an object that allows you to query the last run, next run, and schedule for the currently running job. There should also be some indication of whether the job succeeded for failed to allow for error handling logic to be incorporated into the job.

We use the scheduler service to start a long running job once a day. We want to set the expiration time to one day so that the service is not running in parallel or twice.

For example; Job 2 is dependent on job 1 finishing successfully before it can start.

A job should not start unless all conditions are met besides a scheduled start time. 3 conditions in particular that would be very useful for this; Queued/waiting, failed and successful. Even more useful if a job could be configured to run an action if it has been sitting in a waiting state for x amount of time...

The current update job REST API (with PATCH) in Scheduler does not allow recurrence frequency changing from week to hour, when the "advanced schedule" is set. That is because "advanced schedule" is only meaningful for weekly schedule. I tried to set "schedule=null", but it did not work. This means I have to use a GET to get the Job, and then a PUT to update the Job in this case. I think a better idea would be letting the user to update schedule to be null, and letting them change recurrence frequency from week to hour

Currently Version control is not enabled in Scheduler.
Code checkin and check out and team coding will help

If my backend work takes longer than the http request time (asynchronous) or for queue based requests, I would like to have an API to append status to the history of the job to indicate that the actual backend work is completed.

This would aid debugging services that pull jobs from the queue placed by the scheduler

Reproduce step.

1. Scheduler Job Collection blade > Add
2. Add a job and click OK.
3. Return to Scheduler Job Collection blade, but Monitoring section is not refreshed job list.

So, it would be good to add Refresh button on the Scheduler Job Collection blade.