What changed? Find out faster with centralized deploys in OpsLevel

When an organization adopts microservices, it's normal for the number of deploys to increase. 

Breaking up applications into smaller pieces means teams can deploy their services on their own timelines. Plus, development teams typically move faster when working on services loosely coupled to the broader architecture. Freedom and flexibility mean more gets done.

But shipping more code–and creating more deploy events–also produces noise that makes life harder for on-call engineers and incident responders. That’s why we’ve added a new UX in OpsLevel for reviewing and searching all your deploy events: Deploys across Services.

Latency is up 5x over the last 4 hours–what’s changed?

In this scenario, the service experiencing a sustained latency spike triggers an alert. The on-call is familiar with this service–it powers a critical, customer-facing workflow.

But none of the standard troubleshooting steps documented in the service’s runbook are relevant and the initial investigation hits a wall.

As a next step, the on-call wants to explore the status of the upstream services. No other monitors have been triggered, so the natural next question is has anything about these services changed recently?

Since OpsLevel unifies ownership, dependency, and deploy information engineers can answer this question faster–no wild goose chase required. 

With our new top-down view into deploys, OpsLevel users can filter by environment and time and quickly drill into the relevant changes. The on-call spots a flurry of deploy events for one of the upstream services that just preceded the spike in latency four hours ago–seems suspicious!

From there, the next steps are straightforward–ownership contact info, runbooks, and metrics dashboards are all linked from that service’s detail page in the OpsLevel catalog.

Fewer tabs, fewer clicks, and more visibility

When you aggregate deploy events in OpsLevel, you’re not just helping incident responders. You’re also making ongoing development activity more legible and discoverable for your whole team. When deploys were less frequent this wasn't a big deal.

But with distributed architectures and continuous deployment, access to a clear, unified view of all the changes is vital. It removes friction, keeps teams on the same page, and helps developers work more efficiently.

Something as simple as surfacing in OpsLevel which developer pushed a particular change–that you have an urgent question about–can save precious time and clicks.

Using multiple deploy tools across your organization? Not a problem. All OpsLevel users can browse those deploy events, even if they don’t have access to (or even know how to use) the underlying systems.

If you’re all-in on capturing change events in OpsLevel, you’re not limited to deploys either. Push us any event payloads–feature flag change, infra config changes, etc–that map to services in your catalog and they’ll be available in the new global view, as well as on the Operations tab of each service. 

Why wouldn’t you make it easy for your team to stay informed?

Get started today

OpsLevel integrates with any deploy tool you use. Learn more about the setup in our docs. If you have questions about centralizing deploys or are ready to get started on your catalog, request your custom demo today.