# How CentOps works: sources, service map, end-to-end management

> Connect monitoring and discovery, CentOps builds the service map and you run incidents, changes, patching and architecture on it. No dozens of connectors.

URL: https://centops.app/en/solutions/
Language: en
Last updated: 2026-10-30

How it works

# How it works

Three steps from first data to running your services. No six-month implementation project.

1.  01
    
    ### Connect your sources
    
    Monitoring sends events; discovery or an import provides configuration items. You need no other integrations.
    
2.  02
    
    ### CentOps builds the service map
    
    Items, relationships and owners form one dependency map. Events are matched to items and grouped into situations.
    
3.  03
    
    ### Run services end to end
    
    Incidents, problems, changes, patching and the architecture roadmap all work on the same map and the same impact calculation.
    

What makes CentOps different

### One dependency graph

Incidents, changes, patch plans and monitoring situations all calculate impact the same way, including clusters, replication and mirrored storage.

### Integrations at the source only

Connect monitoring (Zabbix, Prometheus or commercial tools) and discovery. No dozens of connectors to other systems to maintain.

### From alert to roadmap

Operations, changes and architecture in one application. What breaks today feeds the plan for next quarter.

One map from monitoring alerts up to capabilities and the roadmap. Switch to ArchiMate to see the same estate as an enterprise architecture model.

Challenges

## Challenges we solve

IT operations rarely fail on technology. They fail because nobody has the full picture: who the owner is, what depends on what, when production may be touched and what it costs.

01

### A CMDB nobody trusts

Data goes stale, people keep their own spreadsheets and ask colleagues during incidents.

**Solution**Versions and history for every change, data quality checks, discovery, import and sync with a primary CMDB.

[Read the article →](https://centops.app/en/blog/cmdb-nobody-trusts/)

02

### Impact discovered after the outage

Whoever plans a change often does not know which services it will hit.

**Solution**A layered dependency map, outage simulation and impact calculated before a change is submitted.

[Read the article →](https://centops.app/en/blog/impact-before-outage/)

03

### Approvals lost in email

Outages, requests and prices are approved in different channels and nobody knows what is pending where.

**Solution**One approvals queue, one ownership rule, every rejection with a reason.

[Read the article →](https://centops.app/en/blog/change-approvals-without-email/)

04

### Patching as a monthly negotiation

Every window is negotiated again and critical vulnerabilities wait.

**Solution**A patch agreement with the service owner, a pre-approved window, wave plans and an expedited mode.

[Read the article →](https://centops.app/en/blog/patching-without-monthly-negotiation/)

05

### Thousands of alerts, no situation

Monitoring reports symptoms, not causes. People stop reading.

**Solution**Deduplication, suppression during changes and grouping into situations using CMDB topology.

[Read the article →](https://centops.app/en/blog/monitoring-noise/)

06

### Costs not linked to services

Cloud and data centre invoices cannot be attributed to services or customers.

**Solution**FOCUS cost import, costs by service and customer, a price list with an owner.

[Read the article →](https://centops.app/en/blog/what-does-a-service-cost/)

Use cases

## Use cases

Everyday operational situations and how one shared dependency map helps.

01

### Planned outage of a database cluster

The change manager creates a change. CentOps calculates the affected services, offers a slot inside the maintenance window and outside any freeze, and sends the outage to the service owners for approval. Alerts from affected servers are suppressed during the change.

02

### A storage failure at night

Monitoring sends hundreds of events. CentOps groups them into one situation with a probable cause in storage, opens a major incident with the affected services and escalates to the vendor according to the service contract.

03

### A critical vulnerability on a Friday

The scanner import flags an actively exploited flaw. CentOps shows the affected servers and services, sets a deadline by severity and creates a change in one step from the patch agreement’s expedited mode.

04

### Monthly billing data

Costs from clouds, OpenShift and the data centre are loaded in FOCUS format, converted at the Czech National Bank rate and broken down by customer, project and service. Finance gets the data without spreadsheet work.

05

### Shared services for many customers

A provider runs one platform for dozens of organisations. A customer’s users see only their own data, including costs; resolvers work across customers and the service owner approves the price list.

06

### Alongside a primary CMDB

The enterprise keeps its CMDB in another tool. CentOps syncs with it via external IDs and adds the operational layer: impact maps, changes in windows, patching and costs.

Next step

## Try CentOps on your own services.

Connect monitoring and discovery and see your service map within the first week. The beta is free for 6 months.

[Join the beta →](https://centops.app/en/beta/)