@Pradeep James , I see you have posted another question on the WebJob (here), just want to confirm if these are related to the same WebApp/WebJob or it’s isolated/I have already responded on your other thread.
Just to clarify, I believe you’re referring to App Service on Windows and not on-prem servers?
Kindly review the ‘settings.job’ file and the CRON expression. It is best to deploy the settings.job as part of the WebJob.
In Azure environment, the scheduled webjob will only run on one instance (or worker). This is achieved by using file lock mechanism while the webjob is running. If the webjob happens to run for a very short time, there could be a race condition (such as clock sku) to cause another instance to later start up on the same schedule (since it detects no lock). The workaround is to make sure the webjob run for a certain period of time
(say at least 5 seconds assuming schedule interval is greater).
Just sharing as additionally info:
- There are really 2 sites for each Web App: the normal site and the SCM site (which runs Kudu/WebJobs). Each gets a ping, which is why you see two (the ~1 name is the scm site). See this discussion thread.
- As mentioned on the other thread, ensure it is deployed in the right directory/ triggered job copy your binaries (multiples) to: d:\home\site\wwwroot\app_data\jobs\triggered{job name}
Kindly check this document for more details - https://github.com/projectkudu/kudu/wiki/WebJobs#scheduling-a-triggered-webjob
3.On the App Service, In the left navigation, click on Diagnose and solve problems
– Checkout the tile for “Diagnostic Tools
” > “Availability and Performance
” & "Best Practices". /Review the WebJob details.