Services
Every service you watch, worst first: up or down, how fast it answers and what it is handling. Services you deploy through Varcio are watched automatically.
Service Monitoring
Know what is up, where, and what an outage costs
Varcio Service Monitoring shows whether everything you run is up and how it is doing: services, domains and regions across every connected cloud, with incidents, reliability objectives, a public status page for your customers and a labelled estimate of what an outage cost.
- checkout-apiAWS · eu-west-1 · every 1 minUp
- customer-portalAzure · West Europe · domain + certificateUp
- payments-dbAWS · us-east-1Slow
- auth-serviceGoogle Cloud · europe-west4Incident
3Ways to register a service: deploy, discovery or manual
1 minFastest check interval, on Enterprise
4 cloudsCloud provider status pages matched to your regions
14Screens, from estate health to the public status page
Coverage
What Service Monitoring watches
One set of checks feeds detection, response and customer communication, so the status page, the incident and the report all agree.
- ServicesWorst first
- DomainsCertificates and DNS
- RegionsSide by side
- Cloud estateWhat needs you
- TrafficRequests and errors
- Cloud statusProvider pages
Domains and websites
Every hostname you own and whether it is healthy: certificate and registration expiry, DNS records that point at something deleted, and HTTPS settings. Read from your DNS zones, or added by hand.
Regions
Every region and cloud you run in, side by side: availability, response time, traffic and what each costs.
Cloud estate
The health of everything your connected accounts hold, read from the clouds’ own signals across AWS, Azure, Google Cloud and Oracle: what needs you, what changed since yesterday and what could not be read.
Traffic
How much is arriving across everything you watch and how much of it fails: requests, server errors and data served by cloud, region, service or domain, beside what the busiest services cost.
Cloud status
What AWS, Azure, Google Cloud and Oracle report on their own status pages, matched to the clouds and regions your services run in, so you can tell whether it is you or the cloud.
Setup
Three ways to put a service under watch
Registration is a convenience on top of delivery. It never blocks a release.
- By DeployA live release registers where it went
- By discoveryAdopted from your inventory
- ManuallyAny public URL
By Deploy
A successful live release registers every place it went, with what the cloud needs to read it back: the cluster, service, target group, container app or Cloud Run service.
By discovery
Endpoint-bearing resources already in your inventory are offered to you. Nothing is checked until a person adopts one.
Manually
Add any public URL. Useful for third-party dependencies, marketing sites and anything that does not live in a connected account.
Detection and response
Incidents that are confirmed, opened once and closed on recovery
The engine decides, the runner reconciles, and a dropped notification or a restart can never leave an incident the engine no longer believes in.
- DetectedCheck fails
- ConfirmedSecond check
- AcknowledgedSomeone owns it
- AssignedNamed person
- ResolvedClosed on recovery
- PostmortemFrom the timeline
A failure is confirmed by an immediate second check before it is believed. At fast cadences it must also repeat on the next tick, so a service checked every minute is not declared down by one dropped request. Slowness is judged the same way, over consecutive checks.
Outages, slow spells, certificates running out and cloud alarms are each opened once, alerted once and closed on recovery. Alarms never count as evidence of customer impact, because they are your own thresholds rather than your customers’ experience.
The incident workflow
- Acknowledge: someone is on this, without closing or hiding it
- Assign it to a named person in your organisation
- An append-only timeline of system events and human notes
- Live correlation: the release that preceded it, other services in the same region failing, and the provider’s own incident
- Impact from failed checks and, where the cloud is read, failed requests in the window
- A postmortem written by a person from the recorded timeline
- One re-announcement if a critical incident goes unacknowledged
Business impact
An outage cost estimate you can disagree with
It is labelled an estimate, never presented as a measured loss, and every input is shown so leadership can challenge it.
42Impaired minutes×$85Revenue per minute×0.25Share at risk (warning)
=$893Estimate, not a measurement
The estimate
impaired minutes × revenue per minute × the share of revenue the incident put at risk
The impact share defaults per severity (critical 1.0, warning 0.25) and your workspace can change it. The service’s own running cost and the cost of responders are separate figures and are not added in.
Manual rate
A revenue-per-minute figure you type into settings.
Stripe average
The mean takings of a connected Stripe account in the same clock window on the previous seven days.
Real-user conversions
The median value of conversions Real User Monitoring recorded in those hours.
The three sources are shown side by side and never merged, so you can see which one you are relying on.
Reliability
Objectives, error budgets and monthly reliability reports
Make a reliability promise, see what was delivered and how fast the error budget is being spent, then hand the report to a customer or a board.
62%budget left
- Budget spent38%
- Budget left62%
Objectives
Availability and latency promises for a service or a chain of services: what was delivered, how much error budget is left and how fast it is being spent.
Reliability reports
A monthly report of availability, downtime, incidents and planned maintenance per service, ready to hand to your own customers or a board.
Insights
Every service’s month day by day, incidents and maintenance on one clock, when things tend to break, what lapses next and what you pay against how it ran.
Customer communication
A public status page that leaks nothing
It shows only what you chose to show.
- Web applicationOperational
- APIDegraded
- DashboardOperational
The page shows a title, the components you named, their status and uptime, and the notices you post. It never shows a URL, region, error message, cloud or the name of the service behind a component. An unpublished page answers exactly like a page that does not exist, and everything typed into it is stored as plain text.
A posted notice can make a component’s status worse, never better, so nobody can paper over a failing check. Uptime bars are the pooled availability of a component’s services for each UTC day, excluding checks made during planned maintenance. A day with no checks shows as no data, never as up.
How status is banded
- 99.9% and above: operational
- 99% to 99.9%: degraded
- Below 99%: outage
- A component whose every check is late shows no data, never operational
- Planned maintenance holds alerts and leaves downtime out of availability targets
Plans
Service Monitoring by plan
Available from the Pro plan. Limits are enforced by the platform, not only displayed.
| Pro | Business | Enterprise | |
|---|---|---|---|
| Monitored services | 5 | 25 | 200 |
| Check interval | 1 h, 4 h or 1 d | 15 min, 1 h, 4 h or 1 d | 1 min, 5 min, 15 min, 1 h, 4 h or 1 d |
| Monitoring depth | Outside-in | Cloud | Full |
| History | 30 days | 90 days | 400 days |
Scroll sideways to see the full table.
Connected
Part of the same platform as cost
Reliability and cost move together, so the data is shared.
- DeployRegisters services
- MonitoringChecks and incidents
- ReleasesIncident correlation
- Real usersConversion value
Deploy & Migration
Services you deploy register themselves, with the cloud references needed to read them back.
Releases
Incident correlation reads the release that preceded an incident from Engineering FinOps.
Real User Monitoring
Conversion value from real visitors feeds the outage-cost estimate, and real users sit beside synthetic checks.
FAQ
Questions, answered
What is Service Monitoring?
It shows whether the services, domains and regions you run across your connected clouds are up and how they are performing, and it runs incidents, reliability objectives and a public status page from the same checks.
How does it avoid false alerts?
A failure is confirmed by an immediate second check before it is believed, and at fast cadences it must also repeat on the next tick. Slowness is judged over consecutive checks. Each incident is opened once, alerted once and closed on recovery.
How is the outage cost calculated?
It is impaired minutes multiplied by revenue per minute and by the share of revenue the incident put at risk. It is labelled an estimate, the rate comes from up to three sources shown side by side, and the impact share is editable.
Does the public status page expose internal details?
No. It shows only the title, components, status, uptime and notices you chose. It never shows URLs, regions, error messages, clouds or the services behind a component, and an unpublished page answers like a page that does not exist.
Which plans include Service Monitoring?
Pro, Business and Enterprise. Pro monitors up to 5 services, Business up to 25 and Enterprise up to 200, with faster check intervals and longer history on higher plans.
See the health of everything you run
Connect a cloud account and put your first services under watch. Free trial, no credit card required.