Checklist after deployment

Once you have finished deploying or upgrading ILAP Analytics, work through this checklist to confirm that every component — the API, background jobs, GraphQL, the web UI, and time-phasing — is healthy and processing schedules correctly. It is written for the IT administrator who has just completed an installation and wants to verify the environment before handing it over to users.

1. Go to the health endpoint of the api (apiUrl/health). Make sure all the statuses are healthy.
2. Go to the health endpoint of the background job(bgJobBaseUrl/health). Make sure all the statuses are healthy.
3. Go to background job dashboard (bgJobBaseUrl/jobs) and check if there is any recently failed jobs. There should be no failed jobs.
4. Go the graphql url (apiUrl/graphql) and check if the page is loading to check the if graphql is working or not.
5. Go to Ilap analytics web UI, try loggin in. → Web UI is working fine
6. After login, Go to the Field Section, check if the fields are being shown. → API is working fine
7. Check test connection from IDE desktop client → Analytics api is accessible by the user
8. Import a schedule, go to hangfire dashboard, check if jobs are being processed → hangfire dashboard is working fine.
9. Import a schedule with resource assignment and planned hours, wait for the background jobs to be finsished, log into the analytics database and check if there were new entries in the table “Reporting_ActivityPeriodized” → timephasing is working correctly

If a check fails

If a health status is unhealthy, a component cannot reach SQL, blob storage, Key Vault, the IDE / ILAP Data Exchange API, the Timephasing API, or DNS — most often after the environment has been secured. The deployment package includes a troubleshooting guide and diagnostic scripts under Azure.IaC/Reference-Security/:

• TROUBLESHOOTING.md — a symptom → cause → verify → fix guide for every communication line, plus an "if you cannot SSH in" path for locked-down environments.
• Scripts/diagnose-connectivity.azcli / .ps1 — run from an admin machine (no SSH needed) to check the private path: public-access state, private endpoints, private DNS records, and VNet integration. Start here.
• Scripts/diagnose-connectivity.sh — run inside the API or Background Jobs container over SSH to test each line live.
• Scripts/connectivity-queries.kql — Log Analytics queries for reading the failures after the fact.