On-Call User Guide

MicroGemLabs ships one on-call engine that is shared across every product on the platform — PulseGuardPlus, CronKeeper, LogVault, CertGuard, CronRunner, and HookRelay. Configure it once and any incident (monitor down, cron missed, log spike, cert expiring, scheduled job failing, webhook endpoint flapping) routes through the same schedules, policies, and contact channels.

Adding someone to your on-call rotation is a three-step process. They first have to exist as a member of your team, then they get added to a schedule, then the escalation policy decides when they get paged.

1. Invite the user to your team

Go to Team → Members (/team). Click Invite Member, type the user's email, and click Invite. They receive an email with a link; clicking it (and signing in with magic link if they don't already have an account) lands them on your team as a member.

Only team owners and admins can invite. The team owner can promote a member to admin from the same page.

2. Add them to an on-call schedule

Go to Ops → On-Call → Schedules (/oncall/schedules). If you don't have a schedule yet, click New Schedule to create one. A schedule has:

• Name — e.g. "Primary On-Call", "Weekend Coverage"
• Rotation type — single user (always-on), round-robin (rotates through participants), or follow-the-sun (time-zone-based handoff)
• Participants — the team members in the rotation. Add your invited user here. Each participant has a rotation order.
• Active flag — schedules can be disabled without deleting them

A team can have multiple schedules running in parallel — for example, a "Primary" schedule covering everyone and a "Database Specialists" schedule that only the DB-savvy members rotate through. The escalation policy picks which schedule to use for each step.

3. Wire the schedule into an escalation policy

Go to Ops → On-Call → Policies (/oncall/policies). Click New Policy (or edit the default one).

An escalation policy is an ordered list of levels. Each level fires after a configurable delay (e.g. 0 min, 5 min, 15 min) and points at one of:

• A specific user (always pages this person)
• An on-call schedule (pages whoever is currently on duty)
• An external webhook (forwards to PagerDuty, Opsgenie, etc.)

Typical setup: Level 0 → Primary schedule, Level 1 → Secondary schedule after 5 min if unacknowledged, Level 2 → Team-channel Slack DM after 15 min. Acknowledging the alert (via SMS reply, web link, or messaging-bot button) stops escalation.

Each product (PulseGuardPlus, CronKeeper, etc.) has a setting for which policy applies to its incidents. By default it's the team's only policy; if you've created multiple, pick the right one from the product's settings page.

4. Configure how the user receives alerts

Each user controls their own contact channels at Account → On-Call Contact Preferences (/account). The available channels are:

• Email — always enabled, uses the email they signed up with
• SMS — needs a phone number, requires Twilio creds on the platform
• Voice call — same Twilio path as SMS, used for high-severity alerts when SMS hasn't been acknowledged
• Slack DM — needs the platform Slack bot connected (Settings → Integrations) and the user's Slack ID linked
• Telegram DM — paste your Telegram Chat ID into the Account page; the platform's Telegram bot then DMs you directly

Tell the user to set their contact preferences before they start being paged. Without contact prefs the platform falls back to email-only.

If someone needs to swap an on-call shift (sick day, vacation, conference), use Ops → On-Call → Schedules → [schedule] → Overrides to assign their slot to a teammate for a specified window. Overrides apply on top of the base rotation; the base resumes automatically after the override window ends.

When an alert fires, the on-call engineer can acknowledge it via:

• SMS reply — reply ack to the alert SMS
• Voice call IVR — press 1 during the call
• Web link — every alert includes a signed acknowledge link
• Slack/Telegram button — tap the Acknowledge button in the bot message
• Dashboard — click Acknowledge on the incident card at /dashboard or in the bell-icon notification list

Acknowledging stops further escalation steps from firing. Resolving the incident (separate action) closes it out.

The same on-call configuration covers every MicroGemLabs product. You don't set up on-call separately for PulseGuardPlus and CertGuard — both route through the same schedule and policy. This is intentional: an outage rarely respects product boundaries, and one rotation makes accountability simple.

The product-specific settings page (Settings → Routing on each product) lets you override which policy applies to that product's incidents if you've created more than one.