Questions, answered

Click Get started, then use Proto to configure Server Monitoring for your business. Begin with one service, its linked assets, an owner and a responder. Rehearse a failed check through acknowledgment and recovery before adding further coverage.

It records a time, success result, latency, probe location and service. Compare the result with other checks and server samples before deciding how broadly the service is affected.

A sample belongs to an asset and records CPU, memory and free disk observations. An incident can name the affected asset and service so the responder can compare those readings with the investigation.

The incident has an assigned person. An on-call shift shows the planned responder for a service and time window. The team should confirm the actual handoff with acknowledgment and response events.

The responder records a site, outage reference, start and restoration time against an incident. The service owner can add a separate impact classification for the affected service.

A Change Reviewer records the decision and reason in the change review. The Release Operator uses that decision before implementation and records the deployment outcome.

Review the deployment state, rollback checkpoints and a new availability check for the service. Resolve any related incident only after the team confirms the observed result.

Runbooks have an owner, linked service, publication state and procedure body. Responders can use published runbooks during investigation and leave feedback afterward.

Integration receipts retain the provider, external event identifier, receipt time, payload hash and disposition. Review rejected or failed receipts apart from the incident queue.