Straight answers to the questions we get most.

Our access to your systems is least-privilege and logged, and every action we take lands in your own cloud audit records, attributed to a named engineer, so you can verify what we did without taking our word for it. And the same engineers have managed customers' production since 2005 at Server Surgeon.

No. You set the guardrails and escalation rules, the lines we don't cross. We handle whatever comes up within them, and we bring anything beyond them straight to you. Nothing happens automatically: your rules appear on the engineer's screen next to the alert, and a person reads them and decides. Anything past the lines you've drawn, like failing over a database or restoring from a backup, starts with a call to you. See Cloud Monitoring Service →

No. Only alert notifications reach us. Your metrics and log content stay in your environment, and our monitoring access is prevented by design from reading your application data. You can verify that in your own cloud audit records. See how we monitor →

We catch and handle production incidents, not just alert you. We begin responding to critical alerts within 10 minutes, a real engineer engaged, not just an auto-acknowledgement.

We document your environment during onboarding and use any playbooks you share. But you don't have to write any for us. The engineers have managed customers' production since 2005, and cloud environments since AWS launched EC2 in 2006, so they know how to operate a system they've just been handed.

For cloud resources, no: that monitoring is agentless. For visibility inside your servers, memory, disk, services, databases, we install a small monitoring stack from standard packages into your environment. It runs in your account, and you own it. See how we monitor →

In a limited way, and we're upfront about it. We monitor Windows servers and respond with server reboots and service restarts, and that's where our Windows support ends. Our depth is Linux. If you need more, tell us what you run and we'll be straight about the fit.

Cloud Monitoring Service watches your cloud and handles incidents during the coverage window you choose, priced to your environment. Managed Cloud Services is the bigger handoff: we manage the parts of your operations you choose, from patching and backups to scaling and security, and it can include that same monitoring and response. Managed DevOps Services adds the build half: we build CI/CD pipelines and infrastructure as code, and the team runs what ships. See Cloud Monitoring Service, Managed Cloud Services, and Managed DevOps Services

Yes. We build them in-house: CI/CD on GitHub Actions or Bitbucket Pipelines, infrastructure as code in Terraform, automation with Ansible, and containerized workloads (Docker and Kubernetes). Build work is scoped and quoted as a one-time project, and the same team can run what gets built. See Managed DevOps Services →

You choose: around the clock (24/7), after hours, business hours, or a custom schedule.

Our baseline is a real engineer engaged within 10 minutes on critical alerts and tickets answered within 30 minutes. Need a specific SLA? Tell us what your business requires and we'll work with you to define and meet it.

Cloud Monitoring Service is priced to your environment, never a percentage of your cloud bill. No setup fee, no hidden costs. Managed Cloud Services and Managed DevOps Services are custom-scoped and custom-quoted: ongoing operations as a monthly fee, and DevOps build projects as one-time quoted work. How pricing works →

That's usually a better fit for our parent company, Server Surgeon. The same team has managed individual Linux servers there since 2005, and for a setup that size it's the more cost-effective choice. After Hours Ops is built for full cloud environments: multiple servers, databases, scaling workloads, and the coverage windows around them. Not sure which fits? Ask either team and we'll point you to the right one.

The team behind Server Surgeon. The same engineers have managed customers' production since 2005, with more than 130 years of combined production experience, and that track record is public. About us →

No. Alerts go to our engineers, not to you. When something needs your attention, it becomes a ticket on your account, and the first thing you read is a message written by the engineer handling it, not raw monitoring output.

Support and incident response run through tickets and monitoring, so every action is tracked and nothing slips. You'll also have a named primary technical contact for your account. Not a customer yet? Send a message through our contact page or request a quote, and a real person will reply.

Nothing. It's built in your cloud account, as code, in a repository you own, and it keeps working without us: dashboards, history, and local alerting. Offboarding removes our alert destination, and that's the whole procedure. We've tested it, not just claimed it. See how we monitor →

Month-to-month, with no long-term contract. A 30-day money-back guarantee. No setup fee.