On review_requested:

1. After the delay you set (product default 4 hours), the requested reviewer gets a Slack DM if they have not submitted a human review.
2. At the configured second delay (product default 24 hours from the request), the individual repository owner is escalated if a human review is still missing.

A GitHub bot review does not stop the clock. Only a human review with actor evidence does. People without a confirmed Slack identity are not silently DMed.

The reviewer DM is a reminder with the PR title, status, and GitHub link. The owner DM names the overdue reviewer and the PR.

Review by @reviewer is overdue on org/repository #42: feat: add slug helper

The delays are configurable. Shorten them only to prove the breach path, then restore the operating delays.

Who is in scope

• Requested reviewers with a Slack binding.
• The named individual owner on that repository.

Do not request someone as a reviewer if they must not receive DMs. Catalog 9 (timely acknowledgment) is a finding; the DMs are this chain (pull_request_review_sla).

Propose this when

Requested reviews sit in GitHub with no human review, and reviewers plus the owner have (or can confirm) Slack identities.

Do not

• Name a GitHub team or Slack channel as the owner. Owner is an individual.
• Enable this chain for people whose Slack binding is unknown.
• Treat catalog 9 as a substitute for DMs.

Clocks

The clock starts when Warestack processes review_requested for that reviewer on that PR. Restarting the chain (new version, or a new request) starts a new clock. Proving breach (DM after the delay) is not the same as proving met (review inside the window, no DM).

Before enablement, readiness checks Slack connection, the person-targeted delivery path, requested-reviewer identity coverage, and the individual repository owner. Use Automation activity to confirm delivered, skipped, or failed outcomes.