Questions, answered

Click Get started, then use Proto to configure DevOps Dashboard for your business. Begin with an active service, its owner, a release change, a pipeline run and a deployment environment. Rehearse the CAB decision and an incident handoff before widening the scope.

A change records the service, summary, risk, planned window, rollback plan and status. The CAB review records the reviewer, decision, date and reason. The deployment record then follows the environment result.

A pipeline run records a branch, commit, run time and result for a service. A deployment records the environment, version, time and observed outcome. Read both when deciding whether a release reached the intended environment successfully.

The CAB Reviewer records the advisory decision and reason. The Release Manager uses that decision when moving the change forward. The delivery team works from the approved change and its planned window.

Yes. A deployment can be marked rolled back and include a rollback reference. Rollback checks can retain expected and actual checkpoint results, while the change retains its rollback plan and final state.

Capturing an incident starts the acknowledgement workflow and records the first response event. When investigation starts, the workflow moves the incident into Investigating and adds an attributed update.

Service requests carry requested, due and completed times. The manager can follow active work and compare the completion time with the due date in the request report.

An incident can reference an asset and service. Asset records carry the tag, serial number, location and state, while asset service links record a dependency and verification time.

Start with the systems that provide pipeline results and deployment outcomes, then agree how incident intake identifies the matching service and how provider receipts are investigated by event ID. Test a rejected integration receipt during setup so the team knows how to investigate it.