Operate the server and mobile response workflow with confidence.

Recommended configuration path

Build from responders to verified service response

Oncall server

Server overview

The server is the authoritative system for services, alerts, escalation state, on-call assignments, users, and audit history. Browser and mobile clients display that state and submit actions back to the server.

Foundations

Users and teams

Users

A user represents one responder. Configure the user’s sign-in identity, contact methods, and mobile registration before placing that user in a production rotation.

• Verify the account is active and the authentication source is expected.
• Add and test the contact methods the escalation policy may use.
• Confirm the user can sign in to the mobile app.
• Confirm notification permission and mobile registration status.
• Use overrides for temporary coverage changes instead of editing historical rotation design.

Teams

A team groups responders and owns operational resources. Team administrators can manage the team’s members and owned resources; site administrators retain site-wide control.

Coverage foundation

Rotations and schedules

Rotations answer “who comes next?”

A rotation is an ordered participant list with a handoff cadence. Participants can be users and other supported assignment targets. The current rotation state identifies the active participant.

Schedules answer “who is on call now?”

A schedule applies one or more rules and rotation layers to time windows. Multiple rotations are useful when coverage changes by time of day, weekday, role, or follow-the-sun region.

• Check the schedule preview before using it in a policy.
• Verify time zone and daylight-saving behavior for every coverage rule.
• Use temporary overrides for planned leave or short-term substitutions.
• Confirm the “Who is on call” view matches the expected responder.

Service management

Services and incoming integrations

A service is the protected application, system, infrastructure component, or business capability. It has one owning team and uses an escalation policy when an alert requires response.

Incoming alert paths

Integration verification

1. Create a non-production test service owned by the intended team.
2. Send a realistic payload through the exact production integration path.
3. Verify service, summary, details, priority, and deduplication behavior.
4. Update, acknowledge, close, and reopen the test alert where the integration supports those actions.

Response workflow

Escalation policies

An escalation policy is an ordered set of notification steps. Each step identifies one or more destinations and how long to wait before moving to the next step. The policy continues until the alert is acknowledged, closed, or the configured workflow ends.

Design guidance

• Start with the schedule that represents normal service ownership.
• Add a distinct backup destination instead of repeatedly notifying the same unavailable responder.
• Keep delays short enough for service impact but long enough to let a responder act.
• Test acknowledgement at every policy step and confirm later steps stop.
• Review policy destinations whenever team membership or coverage changes.

Alert operations

Alert lifecycle

Alert state is server-authoritative. A mobile acknowledgement, browser action, or authenticated API request all update the same record. The alert log preserves state transitions and notification activity for review.

Deduplication

An integration can use a stable deduplication key so repeated events update the same alert instead of creating parallel alerts. Use a key tied to the monitored condition, not to a delivery attempt or timestamp.

Operational checks

• Confirm the alert is attached to the correct service.
• Check priority before acknowledging.
• Review notes and log entries for updates from monitoring systems or other responders.
• Close only when the condition no longer needs active response.

Outgoing notifications

Notification channels

Channels are enabled only when their underlying configuration is complete and healthy. A user’s contact method identifies where a notification is sent; policy destinations determine who should be reached.

Protected administration

Authentication, API keys, backup, and recovery

Authentication

Choose the authentication method that matches your organization, configure a public HTTPS URL, and test administrator and responder sign-in before disabling another known-working method.

API keys

Prefer the narrowest scope that can perform the automation. Use a service integration for one service, a team key for team-owned services, and a site key only for approved site-wide workflows. Rotate keys after suspected exposure.

Export and backup

• Use configuration export/import for portable application entities and controlled deduplication.
• Use database backup for complete database recovery.
• Store backups outside the application host and test restoration regularly.
• Protect encryption keys and provider credentials independently from database backups.

Upgrades

1. Read the release notes and confirm platform prerequisites.
2. Create and verify a current backup.
3. Deploy during a controlled maintenance window.
4. Verify readiness, alert creation, escalation, and notification channels.
5. Keep rollback artifacts until verification is complete.

Mobile setup

Install and sign in

1. Install the Virbula Oncall app. Use the approved iOS or Android distribution provided by your organization.
2. Enter the company server URL. Use the public HTTPS address supplied by your administrator. Confirm the hostname before entering credentials.
3. Sign in. The app uses the authentication methods enabled by the company server. Complete browser-based sign-in when directed.
4. Allow notifications. Grant notification permission and, on iOS, allow time-sensitive notifications when prompted.
5. Verify readiness. Confirm the app reports successful server connection, device registration, push notification readiness, and in-app alerts.

Device readiness

Notification permissions and delivery

iOS

• Enable notifications in iOS Settings.
• Enable sounds, badges, and Lock Screen presentation as appropriate.
• Allow time-sensitive notifications for prompt presentation.
• Do not force-quit the app during an on-call shift.
• Review Focus settings so approved time-sensitive alerts can appear.

Android

• Enable notifications for the app and its alert channel.
• Allow sound, vibration, and Lock Screen presentation as appropriate.
• Exclude the app from aggressive battery restrictions when company policy allows.
• Keep background data available during an on-call shift.

Responder workflow

Receive and acknowledge an alert

1. Open the notification. Review priority, service, summary, and the current alert state.
2. Inspect context. Read details, recent log entries, and service ownership before taking action.
3. Acknowledge when you take ownership. The app submits the action to the server and confirms the resulting server state.
4. Coordinate the response. Add notes or use your organization’s connected collaboration workflow while remediation is underway.
5. Close after resolution. Confirm the monitored condition is resolved and the alert no longer requires active response.

Coverage awareness

See who is on call

The mobile on-call views let responders check coverage by service, team, or schedule. Use the service view first when diagnosing an alert because it connects ownership, policy, and current responder context.

• Check your upcoming assignments before an on-call shift.
• Verify temporary overrides appear correctly.
• Contact the team administrator if the server shows an unexpected assignment.
• Do not rely on a cached screenshot or calendar entry as the authoritative current assignment.

Mobile troubleshooting

When alerts or actions do not behave as expected

When filing a support ticket, include the operating system, app version, company server URL, approximate time, alert reference, and a description of the observed result. Never include secrets.

Go-live checklist

Verify the complete path before production

• Public HTTPS and server readiness checks are healthy.
• At least two site administrators have verified access.
• Every production responder has working authentication and contact methods.
• Every on-call responder has installed, signed in, and enabled mobile notifications.
• Schedules, rotations, time zones, and overrides have been reviewed.
• Each service has the correct team owner and escalation policy.
• Each production alert integration has passed an end-to-end test.
• Email, SMS, voice, push, Slack, and webhook channels in use have been tested.
• Acknowledgement stops escalation and close/reopen behavior has been verified.
• Backups run outside the application host and a restoration test has succeeded.
• Monitoring covers the server, database, and enabled notification dependencies.

Virbula Support

Getting help

Search this guide first, then file a support ticket with the affected product area, urgency, instance URL, expected behavior, observed behavior, and approximate time.