Log affected URL when outbound requests are blocked

Problem to Solve

When a URL is blocked by GitLab's Outbound Request filtering, the affected URL is not logged. This makes it difficult for administrators and support engineers to troubleshoot why integrations, webhooks, or other outbound requests are failing.

Currently, when an outbound request is blocked, the logs only contain generic error messages without visibility into which specific URL was blocked. This forces both administrators and support engineers to:

  1. Check application logs for vague error messages
  2. Manually trace through configuration and request patterns to guess which URL was blocked
  3. Spend significant time troubleshooting what should be a straightforward issue

Without knowing which URL was blocked, it's nearly impossible to determine the root cause or provide actionable remediation steps.

Intended Users

  • GitLab administrators managing outbound request filtering
  • Integration/webhook administrators troubleshooting failed connections
  • GitLab Support engineers helping customers diagnose connectivity issues

User Experience Goal

When a URL is blocked by outbound request filtering, both administrators and support engineers should be able to quickly identify:

  • Which URL was blocked
  • Why it was blocked (e.g., local network, not in allowlist, etc.)
  • When the block occurred
  • What action triggered the block (webhook, integration, etc.)

Proposal

Add the affected URL to the log output when outbound requests are blocked. This should include:

  1. Log Entry Enhancement: Include the blocked URL in structured logs (e.g., exception_json.log)

    • URL that was blocked
    • Reason for blocking (e.g., "Requests to the local network are not allowed")
    • Timestamp
    • Context (which feature/integration attempted the request)

  2. Error Message Visibility: Ensure the blocked URL appears in error messages that users/admins can see

    • In Sidekiq logs for background jobs
    • In application logs for synchronous requests
    • In webhook delivery logs if applicable

  3. Consistent Logging: Apply this across all outbound request blocking scenarios:

    • Webhook requests
    • Integration requests (Slack, Jira, etc.)
    • Package registry requests
    • Any other outbound HTTP requests subject to filtering

Benefits

  • Faster Troubleshooting: Administrators can immediately identify which URL is blocked without manual investigation or guessing
  • Better Visibility: Clear audit trail of what was blocked and when
  • Improved Support Efficiency: Support engineers can provide actionable remediation steps instead of asking customers to guess which URLs are being blocked
  • Reduced Investigation Time: Both admins and support teams can quickly determine root cause without extensive log analysis

Permissions and Security

  • Blocked URLs should be logged in admin-accessible logs only
  • Consider redacting sensitive information (API keys, tokens) from URLs if present
  • Ensure logging doesn't expose URLs that should remain confidential

Documentation

  • Update webhook and integration documentation to explain how to find blocked URL logs
  • Document the log format and fields for blocked requests
  • Provide examples of common blocking scenarios and how to resolve them

Testing

  • Verify URLs are logged when requests are blocked by local network filter
  • Verify URLs are logged when requests are blocked by allowlist filter
  • Verify URLs are logged for various integration types (webhooks, Slack, Jira, etc.)
  • Verify sensitive information is properly handled in logs

Availability

This feature should be available for:

  • GitLab.com (for transparency)
  • Self-Managed instances (primary use case for administrators)
  • Dedicated instances