Azure Outage Triage, Browser MCP, Code Security, and Agent Tools

These five projects sit at different layers of the development stack, but they share a practical theme: giving developers better context before they change code.

One is for distinguishing an application failure from a platform outage. Two help agents work with browsers and source code. The remaining projects explore running existing workloads on Azure and creating a self-hosted workspace for human-agent collaboration.

Popularity figures below are a snapshot from November 14, 2026, not a measure of production readiness.

1. Diagnose Microsoft 365 and Azure incidents separately

What it is: Microsoft 365 Status and Azure Service Health provide two different diagnostic signals. The public Microsoft 365 Status page reports broad incidents, while Azure Service Health provides subscription-specific alerts. Azure Monitor and Application Insights add the application-level view.

Why now: A recent Microsoft 365 degradation collected 1,160 points and 977 comments on Hacker News. That level of attention reflects a familiar operational problem: a Graph, SharePoint, Teams, or authentication timeout can look exactly like a bad deployment.

Tutorial angle: Build a short outage-triage runbook:

1. Record the failing request, timestamp, HTTP status, request ID, and affected dependency.
2. Check the public status page and your tenant’s Azure Service Health.
3. Correlate the incident with Azure Monitor metrics, Application Insights traces, and deployment annotations.
4. If Microsoft reports an active incident, add bounded retries, exponential backoff, jitter, and a useful degradation message.
5. If there is no platform incident, inspect the failing span and recent deployment instead.

The goal is not to add retries to every error. It is to make the failure mode explicit before touching working code.

Difficulty: Intermediate

Start today:

• Open Microsoft 365 Status and check Microsoft Graph, SharePoint, Microsoft Teams, and Entra ID for an active incident.

2. Run Cloudflare Workers and Durable Objects on Azure with Open Orange

What it is: rivet-dev/open-orange is an open-source runtime designed to run Cloudflare Workers and Durable Objects on Azure, other clouds, or self-hosted infrastructure without rewriting the application.

Why now: The repository was created on November 12 and accumulated 433 stars within two days. The interest reflects a real constraint: adopting Azure often becomes an application rewrite when the existing code depends heavily on a platform-specific runtime.

Tutorial angle: Use a small Durable Object as an interoperability test:

1. Run the sample locally and record its HTTP and persistence behavior.
2. Deploy the same source through the project’s Azure path.
3. Test state creation, reads, writes, concurrent requests, and object isolation.
4. Compare error handling, observability, and deployment behavior with Cloudflare.
5. Create a compatibility checklist for APIs such as KV, Queues, R2, D1, WebSockets, and model bindings.

“Runs unchanged” should be validated against your actual application. Compatibility with the core Worker and Durable Object APIs does not guarantee that every Cloudflare binding or edge behavior is identical.

Difficulty: Intermediate

Start today:

• Run git clone https://github.com/rivet-dev/open-orange.git to get the runtime and its Azure examples locally.

3. Give coding agents browser-level debugging context

What it is: ChromeDevTools/chrome-devtools-mcp is an MCP server that gives compatible coding agents access to browser debugging context, including console output, network requests, and DOM state.

Why now: The project appeared on GitHub Trending with 67 stars that day and 55,451 total stars. Browser bugs are especially difficult for text-only agents to diagnose because the important evidence is often a failed request, console exception, or incorrect DOM state.

Tutorial angle: Configure the server in VS Code, then debug a deliberately broken checkout or login flow.

A minimal VS Code MCP configuration is:

{
  "servers": {
    "chrome-devtools": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

After that:

1. Launch an isolated Chrome profile.
2. Reproduce the browser error.
3. Ask the agent to inspect the console and failed network requests.
4. Confirm the suspected DOM or application change.
5. Apply the fix and rerun the same browser flow.

Use a dedicated browser profile rather than a production session containing sensitive cookies, credentials, or customer data.

Difficulty: Beginner

Start today:

• Run npx -y chrome-devtools-mcp@latest --help to confirm that the MCP server is available on your machine.

4. Add an AI-assisted security validation gate

What it is: openai/codex-security provides a CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in code.

Why now: The repository was trending with 751 stars that day and 13,129 total stars. Security tooling is becoming more useful when it helps developers reproduce and validate findings instead of adding another unactionable scanner report.

Tutorial angle: Test the workflow on a small application with one known weakness:

1. Create a clean branch and capture the current test results.
2. Run the security scan and save the raw findings.
3. Reproduce one reported vulnerability manually.
4. Classify another finding as a false positive and record why.
5. Ask the coding agent to explain and patch the confirmed issue.
6. Rerun both the security scan and the application tests.
7. Integrate the SDK into CI as a check, but do not automatically merge model-generated fixes.

The important part is the validation loop. An agent-generated patch should be treated like any other proposed change: reproducible, reviewed, tested, and scoped.

Difficulty: Intermediate

Start today:

• Run git clone https://github.com/openai/codex-security.git to inspect the CLI quickstart and example application.

5. Host a Slack-style workspace for teams and AI agents

What it is: agentes-chat/agentes-chat is a self-hosted, Slack-style workspace where teams and AI agents can communicate through channels and direct messages.

Why now: Created on November 9, the repository reached 1,341 stars within four days. It targets a common agent-integration problem: giving agents a shared workspace without introducing another proprietary chat platform.

Tutorial angle: Deploy the workspace to Azure Container Apps and test the agent boundary:

1. Run the project locally with a minimal configuration.
2. Build a container image and deploy it to Azure Container Apps.
3. Store model-provider credentials in a secret store or Container Apps secret reference.
4. Create a dedicated development channel and least-privilege agent account.
5. Test channel messages, direct messages, and permission boundaries.
6. Add logging, retention controls, and a documented process for removing the agent from a channel.

Self-hosting the workspace does not automatically make every prompt private. Prompts sent to a hosted model provider still leave your infrastructure, so the deployment architecture and provider configuration should be reviewed separately.

Difficulty: Intermediate

Start today:

• Run git clone https://github.com/agentes-chat/agentes-chat.git to inspect its deployment options and agent configuration.

Building in public: my lead-gen engine

I’m sharing the latest run of the lead-generation engine that powers this daily research workflow. It discovered 1,776 leads, enriched 201 records, and reported 231 contacted leads. The next build cycle will focus on the gap between discovery and enrichment, while treating these figures as pipeline counters rather than conversion-rate claims.

• Discovered leads: 1,776
• Enriched leads: 201
• Contacted leads: 231

Start with this today

Try the browser debugging workflow because it requires only a few minutes and produces visible evidence:

npx -y chrome-devtools-mcp@latest --help

If the command starts successfully, add the same package to your VS Code MCP configuration and point it at a local test page rather than a production browser session.

Picks of the week

• Best operational workflow: Microsoft 365 Status plus tenant-specific Azure Service Health.
• Most interesting portability project: Open Orange for Cloudflare-compatible workloads on Azure.
• Best browser-agent experiment: Chrome DevTools MCP.
• Best shipping gate: Codex Security with human validation and CI integration.
• Best self-hosted agent workspace: Agentes Chat on Azure Container Apps.

Which of these would you test first, and what result would convince you to move beyond the proof of concept?

Connect

If this kind of post is useful, the easiest way to support the work is to:

• Star / follow on dev.to (you're already here 🙂)
• Follow on X: @devkingov
• Reach out for HK-based dev work — .NET / Azure / system integration / IT security: studio.resurrects.co or email [email protected]
• Subscribe to weekly HK tech posts → studio.resurrects.co/blog (one email a week, no spam)