Managed hosting responsibilities, assigned task by task

What stays with you under any contract

Microsoft's shared responsibility page lists four things the customer keeps under every deployment model, SaaS included: data, endpoints, accounts and access management. Those four stay with you under a managed hosting contract as well. A provider may make an access change on a ticket, but your side decides who has access. What moves is the middle of the stack (the guest operating system, the database engine, backups, monitoring and capacity), and every proposal cuts that middle differently.

The two ends seldom cause disputes. Petrichor runs on hardware we own, so the hardware rows are ours by default, and application code, releases and the definition of "working" stay with your team. The arguments start in the rows between, usually the ones marked "shared".

The number of rows depends on how the environment gets used. Steady application hosting asks little of the provider beyond servers that are configured and supported. A QA team that builds and tears down stacks adds rows a hosting account never touches, such as approved configurations, access gated by team and cleanup of stacks nobody claimed.

First actor, approver and evidence for each task

Fill in the table against the proposal in front of you, alongside the due diligence questions for a managed private cloud provider. First actor means whoever does the task and hears first when it fails. The approver owns the decision inside the task, such as a maintenance window, a spending increase or a recovery point. Evidence is anything either side can show without a meeting to prove the row works. Where two teams share a task, the row says which one starts and what it hands over.

Petrichor customers file tickets for database work, backups and restores, because the people on their side are developers. Keep each approval on the ticket it approves, and the ticket becomes the evidence for every row it touches. We agree the capacity for a workload with you, so the capacity row only has to record who on your side may ask to change it.

Certificates and licenses get left off most matrices, and both carry deadlines. The CA/Browser Forum's Baseline Requirements cap a public TLS certificate issued since March 15, 2026 at 200 days. That cap drops to 100 days on March 15, 2027 and to 47 days on March 15, 2029. A certificate issued today needs replacing within about six and a half months, and one issued after next March within about three. The row needs an owner for the renewal automation and one for the DNS account, because a renewal that validates through DNS fails when nobody can edit the zone.

Windows Server and SQL Server licenses come either from the provider's Services Provider License Agreement (SPLA) or from your own agreement. Bringing your own onto a provider's shared servers takes subscription licenses or licenses with active Software Assurance, under Microsoft's Flexible Virtualization Benefit or, for SQL Server, License Mobility. Record which one applies to each server before the first server is built.

Walking a Windows patch through the matrix

Microsoft publishes its monthly security update on the second Tuesday of each month, typically at 10:00 a.m. Pacific. Take a hypothetical software company, Marlow Creek Software, whose invoicing product runs on one IIS application server and one SQL Server VM. With the patching row filled in, a month goes like this:

1. The provider installs the cumulative update on the QA stack during release week.
2. Marlow Creek's QA lead runs the smoke tests on QA and records the result on the ticket, since only their team can say whether an invoice total is right.
3. The application owner approves a production window, Saturday 22:00 to 23:30 Central.
4. In the window, the provider patches and reboots the SQL Server VM and then the application server, confirms the services are running, and hands back.
5. Marlow Creek's QA lead reruns the smoke tests against production and closes the ticket.

Step 5 catches what the host checks cannot see: a Windows service that the application's installer registered with a Manual start type stays stopped after the reboot, while the provider's monitoring shows the VM up and SQL Server running. sc.exe config <service> start= delayed-auto changes it to start on its own after every reboot, and adding the service to the host checks moves it onto the provider's row.

On Linux, a patch report built from installed packages can show a host as current while it still runs last month's kernel. Ubuntu's unattended-upgrades leaves automatic reboot off by default and signals a pending reboot only with a /var/run/reboot-required file. On Red Hat Enterprise Linux and its rebuilds, dnf needs-restarting -r exits with status 1 when a reboot is due. The evidence column should compare the kernel that uname -r reports with the newest one installed.

One application server means an outage window every month. A second application server and a load balancer keep the application answering while each server reboots, provided session state lives outside the IIS worker process (SQL Server or Redis session state) and both servers share the same machineKey (the Data Protection key ring on ASP.NET Core), so the auth cookie from one server validates on the other. Sticky sessions with in-process state work only if the load balancer drains each server until its sessions expire before the reboot. Petrichor offers load balancing as a paid option. The single SQL Server VM still interrupts writes during its own reboot unless the database gets a second node too. Both changes belong in the proposal before anyone signs the patching row.

Why database work needs two rows

"Database work" in a proposal can mean the engine or the contents, and different people own each. Most managed contracts give the engine to the provider: installs, patches, backups, integrity checks, and index and statistics maintenance. Schema, stored procedures and data fixes ship with your releases, and only your developers know whether a migration can safely run twice.

The two rows meet at the SQL Server recovery model. Your side decides how much data loss the business can accept, and the provider sets the recovery model and the log backup schedule to match. Under the simple recovery model SQL Server takes no log backups, so a request to restore to 14:10, one minute before a bad data fix ran, may land on last night's full backup instead. The full recovery model can reach 14:10 if the log backups cover it, but its transaction log keeps growing until a log backup runs. When log backups stop, the log fills its volume and SQL Server raises error 9002, and the database stays readable while it refuses updates.

Two queries supply the evidence column:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

SELECT database_name, type, MAX(backup_finish_date) AS last_finished
FROM msdb.dbo.backupset
GROUP BY database_name, type
ORDER BY database_name, type;

In the second result, D is a full backup, I a differential and L a log backup. A database in FULL with no recent L row is heading for error 9002, and the first query shows LOG_BACKUP in its log_reuse_wait_desc column. Under SIMPLE, the only restore points are the full and differential backups themselves. Database restore tests for hosted SQL Server and PostgreSQL covers the restore test and what each check proves.

A stalled import job with every host check green

Back at the hypothetical Marlow Creek, customers can sign in, but the nightly import of bank payment files stopped at 01:40. Host CPU sits at 9 percent and disks at 40 percent, IIS and SQL Server are running, and every check the provider watches is green. The bank had rotated its SFTP credential, and nobody hears about it until a customer's bookkeeper calls at 10:00 asking where yesterday's payments went.

Petrichor keeps a person watching its own automation for this reason: a check that only asks whether a process exists will report it running long after it stopped doing its job. The check that catches this failure records the time of the last successful run and alerts at, say, 90 minutes past the expected finish. Your team writes it, since nobody else knows that "finished" means today's rows in the payments table. The matrix records whether Petrichor watches it or you do.

Whoever notices first opens with four facts: what users see, since when, what changed in the last 24 hours (a release, a patch, a credential) and which environment is affected. Severity follows business effect, so your side sets it and talks to your customers. While it works the problem, the provider reports every change it makes to the environment. On Petrichor, that first call goes to named people whose phone numbers the customer already has.

Test the split with three QA tickets

Petrichor starts new customers on dev or QA, usually QA, so production stays where it is while both sides learn the handoffs. Run three requests through the matrix during that period:

• A new QA stack, built by Petrichor from a configuration your QA lead approved and visible only to the team that uses it.
• Removal of a departing developer's access, requested by your side, with Petrichor confirming what it removed.
• A restore of the QA database from a named backup onto a separate target, checked by your QA lead.

Each ticket should name the requester, the approver and the engineer who did the task. When a request lands on work Petrichor does not do, such as web development or interface design, the engineer on the ticket says so and offers to find someone who does. Close each gap in the matrix before the production cutover gets a date.

When to run the servers yourself

Managed hosting adds a handoff to every change. If your team already patches and restores well and wants root on every server, the handoff slows it down for little in return, and unmanaged servers fit better.

An application built on managed services that exist on only one hyperscaler, such as DynamoDB or Azure Service Bus, leaves matrix rows no other provider can own. Keep that workload where it is.

Petrichor runs in one U.S. data center, and geo redundancy is a paid option. A workload that must keep running through the loss of a whole region belongs in a hyperscaler design that spans regions.

Fill in the matrix for the workload you would move first, then book a call and walk a cloud engineer through it row by row. For most teams that workload is QA rather than production.