[simlarsen]

For issue #5123 (a suggested reply to it is at the end).

The problem

Acknowledging a page stops every on-call policy for that incident, alert or episode, for good. When the person who acknowledged it is pulled away, falls back asleep or forgets, the record can sit in Acknowledged with nobody reminded of it. The policy's Repeat only covers the case where nobody acknowledges. The customer's workaround (a workflow that sleeps, re-reads the incident and pages) has to be built per project, and cannot show in the feed or the execution logs that the timeout fired.

The recommendation

Build it, as an advanced, opt-in policy setting with nothing else to decide: it is a real gap that teams moving from PagerDuty expect to be closed (its service-level Acknowledgement Timeout works this way), and the workaround is fragile. What we do not do is move the record back to un-acknowledged: OneUptime never moves a record back up its states (Common/Utils/StateMove), and doing so here would write a state change into its history, email status page subscribers, post to its channels and start every workflow and SLA that waits on a state, all for a reminder. A page again is a run of the policy of its own instead, visible in the feed and the execution logs, and acknowledged, escalated or left alone like any page.

What changed

One policy setting, folded away. OnCallDutyPolicy.acknowledgementTimeoutInMinutes (nullable, no default: off on every policy there is). In the Dashboard it is the Acknowledgement Timeout card under More settings at the bottom of the policy's Escalation Rules page, folded by default (More settings names the card, and says "30 min" while it is on). Its dialog asks one question, If it is acknowledged but not resolved: Don't page again (what every policy does today) or Page again, and only then After how many minutes? (5 to 1440, 30 to start with). Everything else is decided once for everybody, so there is nothing else to pick:

• The clock starts at each acknowledgement, from anywhere (an answered page, the Dashboard, the mobile app, Slack, Teams, the API, a workflow), and starts again at every new one. It is counted from when OneUptime records the acknowledgement, so a back-dated state change does not page anybody at once.
• When it runs out with the record still acknowledged and not resolved, the policy pages again: a new run (pageAgainNumber 1..5) that starts at the level that was paging when it was acknowledged, pages whoever acknowledged it and whoever is on call there now (a rotation that changed hands pages its new person), and goes on through the levels like the first run.
• At most 5 pages again per policy and record, so a record somebody keeps acknowledging is not paged about forever.
• It stops when the record is resolved or deleted, the policy is archived or deleted, or the timeout is turned off; a changed number of minutes applies to the clocks already running.

Server. Common/Types/OnCallDutyPolicy/OnCallAcknowledgementTimeout.ts holds the rule and its words; Common/Server/Utils/OnCall/OnCallAcknowledgementTimeout.ts holds the clock (started from the four state timeline services and from answering a page), the claim (a compare-and-set, so each timeout pages again exactly once across workers), who is paged and the stops. A new minute worker, OnCallDutyPolicyExecutionLog:PageAgainAfterAcknowledgementTimeout, reads only running clocks through a partial index. The run and person-page workers learned that a page again is not over because its record is acknowledged (it was all along), only once the page again is acknowledged or the record resolved. The API and Terraform refuse anything but null or a whole number from 5 to 1440.

What people see. The feed says "On-call policy Payments is paging again (1 of 5): the incident is still not resolved 30 minutes after Dana Kim acknowledged it." The run's status message and its Execution Logs row say "Paged again (1 of 5)". The run's Slack/Teams message says the policy is paging again, and, when nobody answers, raises the same alarm as a first page. The person paged again gets an Acknowledge again button on the record's page beside Escalate (the record's own Acknowledge is gone since it is acknowledged); it answers their page and starts the clock again. Their own call, email, push, Slack, Teams and Telegram message say the record is still not resolved so long after it was acknowledged, and the policy's Escalation summary and Policy at a glance say it pages again (see UI review below). The Escalate wording from #5167 is kept.

Migrations. 1805960000000-AddOnCallAcknowledgementTimeout adds three nullable columns (no rewrite, no backfill); 1805970000000-AddOnCallAcknowledgementTimeoutIndex builds the partial index online. Both numbered after master's newest (renumbered at the last merge, after the code production review's 1805950000000); the drift check is clean.

Docs and words. On-Call Policies gains Page again if it is not resolved and the API field, in all 17 docs languages, line for line, naming each language's Dashboard labels. The 18 new Dashboard strings are translated in all 16 locales.

What changes for existing customers

Nothing until somebody turns it on: every policy starts at Don't page again, and the setting is folded under More settings. The new worker reads an index that is empty until then.

Left out, on purpose

• Moving the record back to un-acknowledged (see above).
• A timeout per severity or per record: one per policy, like Repeat. A severity can use its own policy through on-call rules.
• More choices (who is paged, how many times): fixed, to keep it one decision.
• An Acknowledge for a page again on the mobile app's record page: the person paged again answers it from its email, text or call like any page; a button in the app is a follow-up.

Tests

• Common/Tests/Types/OnCallDutyPolicy/OnCallAcknowledgementTimeout.test.ts: the rule, the bounds, the clock to the millisecond, the cap, the words.
• Common/Tests/Server/Utils/OnCall/OnCallAcknowledgementTimeout.test.ts and OnCallAcknowledgementTimeoutRecords.test.ts (an in-memory world, AcknowledgementTimeoutWorld.ts): fires once per timeout, restarts on a new acknowledgement, stops on resolve, delete, archive and turning it off midway, a changed timeout, minute-edge clock reads, who is paged after the rotation changed hands, the cap, two policies on one record, every record kind, the feed entry, and never throwing.
• OnCallDutyPolicyExecutionLogPageAgain.test.ts, AcknowledgementTimeoutHooksGuard.test.ts (an AST guard that the four state timelines and answering a page start the clock), OnCallPolicyRunMessagePageAgain.test.ts, OnCallPageAgainAcknowledgeAPI.test.ts, OnCallAcknowledgementTimeoutApiAndTerraform.test.ts.
• App workers: PageAgainAfterAcknowledgementTimeout.test.ts and the two ExecutePendingExecutionsPageAgain.test.ts.
• Dashboard (jsdom): the card, the choice, the Escalation page's fold, the Execution Logs row, the record header's Acknowledge.
• Docs: OnCallAdministrationDocsFacts holds the new section to the code; the translation suites hold the 16 translations to it.
• Browser: packages/E2E/AcknowledgementTimeout (offline, real page): folded by default, the dialog, what each save sends, validation, a refused save, 1280 and 390 pixels, dark and German. Wired into Dashboard Offline UI group 9.
• Terraform E2E test 31 now sets the timeout and changes it on update.

What ran locally

• Common npx jest Guard: 162 suites, 5,061 tests passed.
• Common, every suite that imports or reads a changed file, plus the named guards (RequiredColumnsWithDefaultsGuard, RelationListReadCoverage, the credential settings suites, PlanGatedTableLeftovers, TestSendRoutesAskTheRule, PageSearchIndexCovers*, PatternWorkAllowanceGuard, UpdateChecksReadHeldRows, WrongComponentKeyGuard, MoreSettingsOneCard, CardInCardGuard): 249 files, 242 passed and 7 skipped (Postgres-only), 11,053 tests. The 202 server suites among them again with BILLING_ENABLED=true (12 of them need the plans CI sets with billing on, and pass with them).
• App, every suite that imports or reads a changed file, the root-level tests, ShortDescriptionsGuard, CardDescription*, OnCallSimplicityWiring, MoreSettingsOneCardDocs and DashboardLocalesGuard: 88 suites, 6,243 tests; the 41 worker and notification suites again with billing on.
• Docs: Tests/FeatureSet/Docs/Docs*, OnCallAdministrationDocsFacts and Translations, CriteriaGroupsPostmortemsDocsFacts (32 suites, 2,919 tests), docs:check-anchors, i18n:validate, i18n:check, and the Locale suites in Common (37) and App (10).
• The offline browser suite: 9 tests in 18 seconds with its bundle, also with ee/ removed as CI runs it.
• Every migration from an empty Postgres 15, then the schema drift check: clean.
• npm run compile in Common, App and E2E, compile-tests in Common, and tsc --listFiles in Common, App, the Dashboard and E2E (nothing from the root Scripts/ or another package); eslint and prettier on every changed file; the ReDoS checker (no new pattern that is not linear).

Not run locally: the Terraform E2E (needs the full stack), the real-stack Playwright suites, and the whole App and Common suites (only the affected ones, as listed).

UI review

A second agent reviewed every surface this change adds, looked at each one for real, and polished it before merging.

What was looked at. The policy's Escalation Rules page (More settings folded and open, the card, the dialog with each answer, every refusal, a refused save) at 1280 and 390 pixels, light and dark, English and German, through the branch's offline fixture and the real On-Call route group in a harness. The record header for the person paged again (incident and alert) at 1280 and 390, light and dark, English and German, including a failed acknowledge, through the EventOverview fixture with an open page again. The Execution Logs (one policy's and all policies') at 1280 and 390, dark and German. The Escalation summary and Policy at a glance. The run's Slack Block Kit and Teams Adaptive Card messages (paging again, answered, nobody answered, the alarm) and the paged person's Slack/Teams DM and Telegram message, rendered at desktop and phone widths. The call script, the text message, the push and the email (the real template, rendered) that the person paged again receives. The feed entry, the run's status message and the docs section.

What changed, and why.

• The person paged again was told it was a new incident. A page again goes out through the person's own notification rules, worded as a first page: the call said "A new incident has been created", the email's subject "Incident INC-42 created", the push "New Incident", Slack, Teams and Telegram "New incident assigned to you" - to somebody who acknowledged it half an hour ago. Each now says what it is: the call opens "An incident is still not resolved 30 minutes after it was acknowledged", the email's subject is "ACTION REQUIRED: Incident INC-42 still not resolved - ..." and its first line says why, the push is "Incident INC-42 still not resolved: ...", and Slack, Teams and Telegram head it "Incident still not resolved" with the reason under it. Same for alerts and both kinds of episode. The delivery reads once whether its run is a page again (and the policy's minutes); a run that cannot be read is worded as a first page and the page still goes out. Left as they are: the text message (one 160-character part, and it never calls the record new) and WhatsApp (its words are a template Meta approved).
• "Acknowledge" beside "Acknowledged". The header offered the person paged again a bare Acknowledge right next to the record's Acknowledged pill, which read as a button that does nothing. It is Acknowledge again. A failure no longer repeats the button's word as its title: "Could not acknowledge" - "You are still being paged. Please try again."
• The minutes box spoke in the form's words. "After how many minutes? should not be less than 5." and "After how many minutes? is required.", and a fraction (7.5) went through to the server, which refused it. One sentence now covers everything the box may not hold, before anything is sent: "Enter a whole number of minutes between 5 and 1440."
• A policy that pages again now says so where it is read. The setting stays folded under More settings, as asked. But once it is on, it pages people, and the two places a policy is read in a few seconds said nothing about it. The Escalation summary at the top of the same page (updated the moment the card is saved) and Policy at a glance on the policy's Overview now end with "If it is acknowledged but not resolved within 30 min, it pages again, up to 5 times." Durations read like the rest of the summary ("1 hr 30 min"), and the numbers stay whole on a phone. A policy that does not page again reads exactly as before.
• Docs (17 languages): Acknowledge again, and the summaries saying it, each language naming its own Dashboard labels.
• Strings: 7 new keys translated in all 16 locales (a dedicated "up to {{count}} times" plural, since the shared "{{count}} times" reads as a count of occurrences in Russian); the orphaned "Could not acknowledge. Please try again." is gone.

Tests added or changed in the review.

• Common/Tests/Server/Services/OnCallPageAgainChannelMessages.test.ts (49 tests): the words; for each of incident, alert and both episodes, the call, email, Telegram, Slack/Teams message and push of a page again and of a first page; reading whether a delivery is a page again (with and without the policy's minutes, a first run, a direct page that is never read, a read that fails quietly); and a whole delivery through executeNotificationRuleItem handing the notice to each channel, once.
• App/Tests/Notification/OnCallPageAgainEmailTemplates.test.ts: the four page emails open with the page-again line instead of "A new ... has been created", a first page as before, and the line is escaped text.
• Common/Tests/App/Dashboard/AcknowledgementTimeoutPolicySummaries.test.tsx (14): the sentence, its bold and unbreakable numbers, the Escalation summary's row (durations, placement after the last step, absent when off) and Policy at a glance (what it reads, the sentence, absent when off, an out-of-range stored value read as the worker reads it).
• AcknowledgementTimeoutCard.test.tsx: one refusal for 4, 1441, 7.5, 0 and empty; 5, 1440 and 45 taken as typed. AcknowledgementTimeoutEscalationPage.test.tsx: the page hands the card's minutes to the summary, and a save reaches it at once. OnCallPageAgainHeader.test.tsx: Acknowledge again, never a bare Acknowledge, and the failure dialog's title and sentence.
• OnCallAdministrationDocsFacts: Acknowledge again and the summaries sentence pinned to the code.
• Offline browser suite (packages/E2E/AcknowledgementTimeout): the refusal for 4, 1441, 7.5 and empty, and the Escalation summary's line - absent while off, there at once after a save, gone again when turned off. Still 9 tests (assertions added to existing ones), about 25 seconds with its build.

Left alone, on purpose. The all-policies Execution Logs table scrolls sideways at 1280 pixels (its Status pill was clipped the same way before this change). The token pages a text or email link opens ("Do you want to acknowledge this Incident?") read correctly for a page again. The mobile app's Acknowledge for a page again stays the follow-up the builder named.

What ran for the review (after its last edit and its merge of master):

• Common: the 233 suites that name a changed file (222 passed, 11 Postgres-only skipped), npx jest Guard (162 suites), UpdateChecksReadHeldRows, DeleteChecksReadHeldRows, HookWritesCallersMayMake, ListOrderColumnModels, PermissionCatalogueCoverage, and the 37 Locale suites; the notification suites again with BILLING_ENABLED=true and CI's plans.
• App: the 76 suites that name a changed file (Notification, Workers, Docs facts and translations, Dashboard wiring), the root-level tests, DashboardLocalesGuard, NormalizeListOrder, the 10 Locale suites, Tests/FeatureSet/Docs/Docs* (29 suites) and the policies page's own docs suites; docs:check-anchors, i18n:validate, i18n:check (no translation lost).
• ee: the TeamCompliance suites that import the notification service, with ee/ present.
• The added and changed suites again with ee/ hidden, as Common Test and App Test run them.
• The offline browser suite: 9 of 9, about 25 seconds with its build, also with ee/ hidden.
• Type-checks: tsc and compile-tests in Common, npm run compile in App and E2E, the Dashboard's tsc; eslint and prettier on every changed file; the ReDoS checker (no new pattern).

Suggested reply to the issue

Thanks for the detailed write-up. This is now in review as an Acknowledgement Timeout on the on-call policy: under More settings on the policy's Escalation Rules page, choose Page again and after how many minutes (5 to 1440). The clock restarts on every acknowledgement; when it runs out with the incident or alert still unresolved, the policy pages again (the person who acknowledged it, and whoever is on call at that level now), and the feed and execution logs say "Paged again (1 of 5)". It pages again at most 5 times and stops when the incident is resolved. It is off by default. One difference from your proposal: the incident stays acknowledged, because moving it back would notify status page subscribers and channels of a state change; the page again is its own page that can be acknowledged or escalated.

🤖 Generated with Claude Code

[simlarsen]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.