Delete Job


Updated: May 7, 2015

The Delete Job request deletes the specified job. To delete a Scheduler job, send a DELETE request to a job’s address. The full list of a user’s jobs can be deleted by excluding a job ID from the DELETE call (i.e. /jobs). Deleted jobs will have their history purged, and they will never be returned from a subsequent GET call. If you try to DELETE a job that has already been DELETE’d, the Scheduler service will return a response with status code 404.

The Delete Job request is specified as follows. Replace <subscription-id> with your subscription ID, <cloud-service-id> with your cloud service ID, <job-collection-id> with the ID of the job collection, and <job-id> with the ID of the new job itself.


Request URI


To delete one job:<subscription-id>/cloudServices/<cloud-service-id>/resources/scheduler/~/jobCollections/<job-collection-id>/jobs/<job-id>?api-version=2014-04-01


To delete all jobs in the collection:<subscription-id>/cloudServices/<cloud-service-id>/resources/scheduler/~/jobCollections/<job-collection-id>/jobs?api-version=2014-04-01

The following table describes required and optional request headers.

Request Header



Required. Specifies the version of the operation to use for this request. This header should be set to 2013-06-01 or a later version.

The response includes an HTTP status code, a set of response headers, and a response body.

A successful operation returns status code 200 (OK.)

The response for this operation includes the following headers. The response may also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.

Response Header



A value that uniquely identifies a request made against the Management service. For an asynchronous operation, you can call get operation status with the value of the header to determine whether the operation is complete, has failed, or is still in progress. See Tracking Asynchronous Service Management Requests for more information.

Any management certificate associated with the subscription specified by <Subscription-Id> can be used to authenticate this operation. For additional details, see Authenticating Service Management Requests

The following sample URI makes a request for fictional subscription named mysub and fictional cloud service mycs:


The request is sent with the following headers:

x-ms-version: 2013-06-01
Accept: application/json

The request is sent with the following XML body:


After the request has been sent, the following response is returned:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
x-ms-request-id: f1ee9ac55612471aa406d340a372dc77
Date: Fri, 30 Aug 2013 21:00:31 GMT
Content-Length: 0