How to Set Up a Status Page for Azure DevOps in Under 60 Seconds
A step-by-step guide to setting up a public status page directly inside Azure DevOps, including pipeline automation, custom domain configuration, and end-to-end incident testing.
What you will build
By the end of this guide you will have:
- A public status page accessible at `status.yourcompany.com`
- Automatic incident creation when an Azure Pipeline fails
- Email subscriber notifications for status changes
- A tested incident end-to-end — from pipeline failure to customer notification
This guide assumes you are an Azure DevOps Project Administrator or Organisation Administrator. The extension requires the same permissions level needed to install any VS Marketplace extension.
Step 1: Install Status Portal from Visual Studio Marketplace
Open your Azure DevOps organisation. In the bottom-left corner, click the shopping bag icon (Browse Marketplace) or navigate directly to:
https://marketplace.visualstudio.com/items?itemName=Baytek.status-portal-azure-devops&ssr=false#overviewClick **Get it free** and select your organisation from the dropdown. Click **Install**.
Refresh your Azure DevOps page. You should see a new "Status" icon in the left navigation sidebar. Click it to open the Status Portal hub.
The installation takes under 60 seconds. There are no additional infrastructure steps.
Step 2: Configure your components
In the Status Portal hub, navigate to **Configuration > Components**.
Click **Add Component** and create your first service. A component represents a discrete unit of functionality your customers depend on. Good component names are specific:
- API Gateway (not "Backend")
- Build Pipelines (not "CI/CD")
- Authentication Service (not "Auth")
- Dashboard (not "Frontend")
- Artifact Registry
For each component you can optionally assign it to a region. If you serve customers globally, this allows you to show "EU API Gateway — Degraded" without affecting the US or APAC status display.
Step 3: Set up region grouping (optional)
Navigate to **Configuration > Regions**. Click **Add Region** and create regions relevant to your architecture. Examples:
- USA
- United Kingdom
- Europe
- Australia / APAC
Return to the Components view and assign each component to a region. Components not assigned to a region appear in a default "Global" group.
Step 4: Configure your custom domain
Go to **Configuration > Domain**. You will see your default Status Portal URL:
yourorg.status.baytekdev.comTo serve your status page from `status.yourcompany.com`:
1. In your DNS provider, add a CNAME record:
- **Name**: `status` (or your chosen subdomain)
- **Value**: `yourorg.status.baytekdev.com`
- **TTL**: 300 (5 minutes)
2. Back in Status Portal, enter `status.yourcompany.com` in the custom domain field and click **Verify**.
3. Status Portal will provision an SSL certificate automatically. This takes 2–5 minutes.
Once verified, your status page is live at `status.yourcompany.com`.
Step 5: Add pipeline triggers
This is the most powerful feature of Status Portal: automatic incident creation when a pipeline fails.
First, generate an API token. Go to **Configuration > API Tokens > Generate Token**. Copy the token — you will not be able to retrieve it again.
In Azure DevOps, navigate to the pipeline you want to monitor. Open the pipeline YAML file and add the following task at the end:
- task: AzureCLI@2
displayName: 'Create Status Portal incident on failure'
condition: failed()
inputs:
azureSubscription: 'your-service-connection'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
curl -X POST https://api.status.baytekdev.com/v1/incidents \
-H "Authorization: Bearer $(STATUS_PORTAL_TOKEN)" \
-H "Content-Type: application/json" \
-d '{
"component": "Build Pipelines",
"status": "degraded",
"title": "Pipeline failure: $(Build.DefinitionName)",
"body": "Automated incident from pipeline run $(Build.BuildNumber). Investigation in progress."
}'Store your Status Portal token as a pipeline variable. In the pipeline UI, go to **Variables > Add Variable**:
- **Name**: `STATUS_PORTAL_TOKEN`
- **Value**: your token from step above
- **Keep this value secret**: checked
The `condition: failed()` ensures the task only runs when the pipeline fails. The `$(Build.DefinitionName)` and `$(Build.BuildNumber)` are built-in Azure Pipelines variables that automatically populate the incident with the pipeline name and run number.
Step 6: Add a resolution trigger (optional)
You can also automatically resolve incidents when a subsequent pipeline run succeeds:
- task: AzureCLI@2
displayName: 'Resolve Status Portal incident on success'
condition: succeeded()
inputs:
azureSubscription: 'your-service-connection'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
curl -X PATCH https://api.status.baytekdev.com/v1/components/build-pipelines \
-H "Authorization: Bearer $(STATUS_PORTAL_TOKEN)" \
-H "Content-Type: application/json" \
-d '{"status": "operational"}'This restores the "Build Pipelines" component to Operational when the pipeline succeeds.
Step 7: Test the incident end-to-end
Let's verify the entire workflow before relying on it in production.
**Test 1: Manual incident**
In the Status Portal hub, click **New Incident**. Fill in:
- Component: API Gateway
- Status: Degraded
- Title: Test incident
- Body: This is a test incident.
Click **Create**. Open your status page (status.yourcompany.com) in an incognito browser window. You should see:
- The API Gateway component showing "Degraded" status
- The incident listed in the incident history section
**Test 2: Pipeline trigger**
In Azure Pipelines, navigate to a pipeline you have configured with the Status Portal task. Click **Run pipeline** and intentionally make it fail (you can temporarily add a failing step like `exit 1` to a test stage).
After the pipeline fails, return to your status page. Within 30 seconds, you should see an incident automatically created with the pipeline name and run number.
**Test 3: Email notification**
On your status page, subscribe with a test email address. Create another test incident in the Status Portal hub. Check your inbox — you should receive a notification within 2 minutes.
Step 8: Configure notification channels
In **Configuration > Notifications**, you can configure:
**Slack**: Enter your Slack webhook URL. Incident updates will post to the configured channel.
**Microsoft Teams**: Enter your Teams channel webhook URL. Incident updates appear as adaptive cards.
**Email**: Manage subscriber list. Import existing subscribers from CSV if migrating from another provider.
Common troubleshooting
**Pipeline task fails with 401 Unauthorized**
Check that your `STATUS_PORTAL_TOKEN` pipeline variable is set correctly and marked as secret. Verify the token has not expired by going to Configuration > API Tokens in the Status Portal hub.
**Custom domain not verified**
CNAME propagation can take up to 48 hours in some DNS configurations. Use `dig status.yourcompany.com CNAME` to verify the CNAME is resolving. Check that there are no conflicting A records on the same subdomain.
**Incident not appearing on public page**
Ensure the component you specified in the API call exactly matches a component name in your configuration. Component names are case-sensitive.
What to do next
You now have a fully operational status page with automated incident creation. The next step is to communicate the URL to your customers. Common approaches:
- Link from your documentation site
- Add a "System Status" link to your application's footer or help menu
- Include the URL in your terms of service and SLA documentation
- Set up the Slack or Teams notification so your support team sees incidents as they are created
The goal is to make the status page discoverable before an incident occurs, so customers have the habit of checking it rather than emailing support.