Azure DevOps Wiki Knowledge
- Connect your ADO wikis so your agent references your team's runbooks and procedures during investigations
- Wiki content is indexed and searchable — your agent finds the right page automatically
- Supports both managed identity and PAT authentication
The problem: your knowledge lives in wikis nobody searches at 3 AM
Your team has invested hundreds of hours writing runbooks, troubleshooting guides, and operational procedures in Azure DevOps wikis. But when an incident fires at 3 AM, nobody searches the wiki. The on-call engineer opens a dozen tabs, checks Azure Monitor, and either figures it out from memory or escalates — never touching the documentation written for exactly this situation.
The knowledge exists. The problem is access — not to the wiki, but to the right page at the right time, in the context of the actual problem.
How Azure SRE Agent solves this
Connect your Azure DevOps wiki once, and your agent automatically searches it during every investigation:
- Indexes your wiki pages — crawls and indexes all pages from your ADO wiki
- Searches contextually — when you ask a question or an incident fires, your agent searches your wiki alongside other knowledge sources
- References specific pages — responses include citations linking back to the original wiki page
- Picks up updates — reconnect or refresh the connector to re-index updated wiki content
Before and after
| Before | After | |
|---|---|---|
| Incident response | On-call doesn't search wiki during incidents | Your agent searches wiki automatically for every query |
| Knowledge access | Knowledge in wiki goes unused at 3 AM | Runbooks surface exactly when needed |
| Onboarding | New team members don't know which wiki page to check | Your agent finds the relevant page regardless of experience |
| Search quality | Wiki search requires knowing the right keywords | Your agent understands context and finds related content |
What makes this different
Unlike static file uploads, your wiki stays alive. When your team updates a runbook in ADO, your agent picks up the changes — you don't need to re-upload files.
Unlike full-text wiki search, your agent understands context. It doesn't match keywords — it correlates your question with relevant wiki content, combining it with live telemetry from Azure Monitor, logs from Kusto, and other connected sources.
Unlike external MCP-based wiki access, the built-in Documentation connector requires no external server setup. Provide the wiki URL and authentication, and your agent handles the rest.
How it works
The Documentation connector (Azure DevOps service type) crawls your wiki pages and indexes them for search. When your agent receives a query, it searches the indexed content alongside other knowledge sources — uploaded files, web pages, and connected repositories.
The connector supports two types of Azure DevOps content:
| Content type | URL pattern | What gets indexed |
|---|---|---|
| Wiki | https://dev.azure.com/{org}/{project}/_wiki/wikis/{wiki-name} | All wiki pages (markdown) |
| Wiki (scoped) | .../_wiki/wikis/{wiki-name}/{pageId}/Page-Name | Specific page and its subpages |
| Git repository | https://dev.azure.com/{org}/{project}/_git/{repo} | Text files (markdown, docs, code) |
| Legacy wiki | https://{org}.visualstudio.com/{project}/_wiki/wikis/{wiki-name} | Same as above (legacy URL format) |
When you include a page ID in the wiki URL, only that page and its subpages are indexed. This is useful for targeting specific sections like /Operations or /Runbooks without indexing your entire wiki.
How documentation syncing works
Once connected, your agent keeps your documentation index up to date automatically — no manual re-uploads needed.
| Aspect | Details |
|---|---|
| Sync frequency | Auto-crawls every 24 hours |
| Supported formats | .md, .txt, .rst, .adoc, .asciidoc, .wiki, .textile, .org, .htm, .html, .json, .yaml, .yml, .xml, .csv (15 file formats) |
| Indexing process | Documents are chunked, embedded, and indexed for semantic search |
| Updates | Changes in your repository are picked up on the next sync cycle — no manual action required |
Your agent processes each document by splitting it into semantically meaningful chunks, generating vector embeddings, and storing them in a search index. When a query arrives, your agent performs a semantic search across all indexed chunks and retrieves the most relevant passages — regardless of exact keyword matches.
This means your team can update runbooks, add new procedures, or reorganize wiki pages, and your agent reflects those changes within 24 hours.
What you need
| Requirement | Details |
|---|---|
| Azure DevOps wiki | A wiki in your Azure DevOps project with content |
| Authentication | Managed identity (recommended) or Personal Access Token (PAT) |
| Permissions | Read access to the wiki |
Authentication options
| Method | Best for | How it works |
|---|---|---|
| Managed Identity | Production environments | Uses your agent's system-assigned or user-assigned managed identity. Requires adding the identity as a user in your ADO organization. |
| Personal Access Token (PAT) | Quick setup, testing | Generate a PAT in Azure DevOps with Code (Read) scope |
Example: your agent uses a runbook during an incident
After connecting your operations wiki, ask your agent:
Our payment service is returning 503 errors. What does our runbook say to do?
Your agent searches your wiki, finds the "Payment Service Troubleshooting" page, and responds with the documented procedure — complete with a citation linking back to the original wiki page in Azure DevOps.
Related capabilities
| Capability | What it adds |
|---|---|
| Memory & Knowledge → | How your agent uses all knowledge sources together |
| External Observability → | Combine wiki knowledge with diagnostic data |
| Connectors → | How connectors work across all integration types |