SkyOps
M365 Automation & Operations Platform
Internal company tool. SkyOps is built for use inside Castle Rock Sky, where I work as Service Desk Manager. That means I'm intentionally light on implementation specifics here — the architecture and goals are fair game, but the inner workings stay private.
What it is
SkyOps is an internal automation and operations platform for an MSP. It unifies the day-to-day toolchain — Microsoft 365 administration, ticketing, monitoring, billing, documentation, and the rest of the systems a service desk lives in — into a single operational view, and layers automated reporting and remediation on top.
In practice, that means an engineer working a ticket doesn't need to bounce between six different consoles to understand what's going on with a customer or fix a recurring issue. SkyOps pulls the relevant signals together, surfaces what matters, and either fixes the problem automatically or hands the engineer a one-click path to fix it.
Why it exists
MSPs run on a stack of best-of-breed tools that don't talk to each other. RMM in one place, PSA in another, M365 admin in a third, monitoring in a fourth, documentation in a fifth. Every customer interaction means context-switching across all of them, copy-pasting account IDs, and reconciling data that should have been linked from the start.
That tax compounds. Reporting that should take minutes takes hours. Remediations that should run automatically wait for someone to notice the alert. New engineers spend their first months just learning where to look.
SkyOps exists to flatten that. One pane of glass, one source of truth for the data that matters operationally, and as much automation as the underlying APIs will allow.
Architecture
The stack is intentionally simple and serverless:
| Layer | Tech | Role |
|---|---|---|
| Frontend | Azure Static Web Apps | The single-pane-of-glass UI. Fast, cheap to host, easy to deploy from Git. |
| Backend | Azure Function App | Per-endpoint serverless functions handling integrations, automations, scheduled jobs, and the API layer the frontend calls. |
| Identity | Microsoft Entra ID | Authentication for both the frontend and any privileged calls into M365 / Graph. |
Everything runs in Azure under the company's existing tenant. No additional infrastructure to maintain, no servers to patch, no per-seat SaaS bill — billing tracks consumption, which has stayed comfortably small.
The Function App pattern means each integration is its own isolated piece. Adding a new vendor or automation is "write a function and wire it into the frontend" rather than "deploy a service and figure out how it scales."
What it does
Two main jobs:
- Reporting — pulls data from each of the connected systems on a schedule, normalizes it, and produces the recurring operational and customer-facing reports that used to be assembled by hand. The reports go out automatically; engineers spend their time on the exceptions instead of the assembly.
- Remediation — when monitoring or routine checks surface a known issue with a known fix, SkyOps either resolves it automatically or surfaces a one-click action to an engineer. The library of automations grows over time as patterns get recognized.
The unified view ties both together. An engineer can see the full picture for a customer, a user, or a system in one place, and act on it without leaving the tab.
Why I'm building it
The pieces of this kind of platform have been available in the M365 / Azure ecosystem for years — Graph, Functions, Static Web Apps, Entra. What's been missing in most MSPs is the will to glue them together for internal use. Vendors are happy to sell you another dashboard; nobody is going to build the one that actually fits your specific operational reality.
SkyOps is that build, scoped to my company. It's the piece of work I'm proudest of right now — partly because of what it does, and partly because of what it represents: the gap between off-the-shelf tooling and the workflow you actually want to run is almost always small enough to close yourself.