What causes "Webhook request ("%s", to "%s") failed (%s / %s). The request will be retried." in phacility/phabricator?

Fix the receiving endpoint -- check its logs for the failing request from the Phabricator host.

phacility/phabricator · error · Exception

Webhook request (" ", to " ") failed ( / ). The request…

Error message

Webhook request ("%s", to "%s") failed (%s / %s). The request will be retried.

What it means

After a webhook call times out or errors, if the request's retry mode is RETRY_FOREVER the worker records RESULT_FAIL, saves the request, and throws a plain Exception -- which makes the task daemon retry it later with backoff. This is the designed failure path for receivers that are temporarily down; it is transient by construction.

Solutions

Fix the receiving endpoint -- check its logs for the failing request from the Phabricator host.
Verify the network path (DNS, firewall, TLS) from the Phabricator server, not from your workstation.
No Phabricator-side action is required: once the endpoint recovers, the retries will succeed and the request flips to SENT.
If the retry flood is unwanted, change the hook's retry policy away from retry-forever.

Defensive patterns

Strategy: retry

Validate before calling

// Probing a receiver before enabling retry-forever:
PhabricatorEnv::requireValidRemoteURIForFetch($uri, array('http', 'https'));
// then a cheap GET/HEAD from the Phabricator host confirms reachability

Try / catch

// The worker already retries with backoff; in adjacent tooling mirror that:
try {
  deliver();
} catch (Exception $ex) {
  // transient: schedule retry with exponential backoff, cap concurrency
  scheduleRetry($ex);
}

Prevention

Set retry-forever on hooks pointing at services with occasional deploys; use limited retries for strict ones.
Watch request RESULT_FAIL counts as an early signal that a receiver is down.
Keep receiver timeouts shorter than the worker task lease so retries are not duplicated.

When it happens

Trigger: The receiver returned 5xx, refused the connection, or timed out, and the hook is configured to retry forever; each retry that still fails rethrows this exception.

Common situations: Target service restarting or deploying; slow endpoint exceeding the HTTP timeout; network blips between Phabricator and the receiver.

Related errors

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/66ce8f088e78fd7f. Report an issue: GitHub.

Appendix: source

Thrown at src/applications/herald/worker/HeraldWebhookWorker.php:219

    }
    $error_code = $status->getStatusCode();

    $request
      ->setErrorType($error_type)
      ->setErrorCode($error_code)
      ->setLastRequestEpoch(PhabricatorTime::getNow());

    $retry_forever = HeraldWebhookRequest::RETRY_FOREVER;
    if ($status->isTimeout() || $status->isError()) {
      $should_retry = ($request->getRetryMode() === $retry_forever);

      $request
        ->setLastRequestResult(HeraldWebhookRequest::RESULT_FAIL);

      if ($should_retry) {
        $request->save();

        throw new Exception(
          pht(
            'Webhook request ("%s", to "%s") failed (%s / %s). The request '.
            'will be retried.',
            $request->getPHID(),
            $uri,
            $error_type,
            $error_code));
      } else {
        $request
          ->setStatus(HeraldWebhookRequest::STATUS_FAILED)
          ->save();

        throw new PhabricatorWorkerPermanentFailureException(
          pht(
            'Webhook request ("%s", to "%s") failed (%s / %s). The request '.
            'will not be retried.',
            $request->getPHID(),
            $uri,

View on GitHub (pinned to 5720a38cfe)