diff --git a/app/services/ci/create_commit_status_service.rb b/app/services/ci/create_commit_status_service.rb
index f34f309c8ad29a4015b3f6ce0b918e90d1d18f48..2e8dc139ebdee45e5af4d18acdf043687499b3c0 100644
--- a/app/services/ci/create_commit_status_service.rb
+++ b/app/services/ci/create_commit_status_service.rb
@@ -134,6 +134,39 @@ def external_commit_status_exists?
     end
 
     def find_or_build_external_commit_status
+      # Instrument: Check if there are existing statuses for same commit/ref/name but different users
+      existing_statuses_different_users = ::GenericCommitStatus
+        .running_or_pending
+        .for_project(project.id)
+        .in_pipelines(pipeline)
+        .in_partition(pipeline.partition_id)
+        .for_ref(ref)
+        .by_name(name)
+        .where.not(user: current_user)
+
+      if existing_statuses_different_users.exists?
+        # Log detailed information about the collision
+        Gitlab::AppJsonLogger.info(
+          class: self.class.name,
+          event: 'external_commit_status_user_collision',
+          project_id: project.id,
+          pipeline_id: pipeline.id,
+          commit_sha: sha,
+          ref: ref,
+          status_name: name,
+          current_user_id: current_user.id,
+          existing_user_ids: existing_statuses_different_users.pluck(:user_id),
+          existing_status_count: existing_statuses_different_users.count,
+          subscription_plan: project.actual_plan_name
+        )
+
+        # Increment counter metric
+        external_commit_status_collision_counter.increment(
+          project_path: project.full_path,
+          ref_protected: project.protected_for?(ref).to_s
+        )
+      end
+
       external_commit_status_scope(pipeline).find_or_initialize_by( # rubocop:disable CodeReuse/ActiveRecord
         ci_stage: stage,
         stage_idx: stage.position
@@ -205,6 +238,13 @@ def create_log_entry
       )
     end
 
+    def external_commit_status_collision_counter
+      @external_commit_status_collision_counter ||= Gitlab::Metrics.counter(
+        :external_commit_status_user_collisions_total,
+        'Total number of external commit status user collisions detected'
+      )
+    end
+
     def not_found(message)
       error("404 #{message} Not Found", :not_found)
     end
diff --git a/config/prometheus/external_commit_status_collisions_dashboard.yml b/config/prometheus/external_commit_status_collisions_dashboard.yml
new file mode 100644
index 0000000000000000000000000000000000000000..028d050d13d3a2a194048a425a34622442911f9e
--- /dev/null
+++ b/config/prometheus/external_commit_status_collisions_dashboard.yml
@@ -0,0 +1,87 @@
+# External Commit Status User Collisions Monitoring Dashboard
+# This dashboard tracks collision frequency, affected projects, and usage patterns
+# for the external commit status user collision detection feature.
+
+dashboard:
+  title: "External Commit Status User Collisions"
+  description: "Monitor collision patterns when multiple users post status updates for the same commit"
+  tags:
+    - ci
+    - external-jobs
+    - buildkite
+    - commit-status
+  
+  panels:
+    - title: "Collision Rate Over Time"
+      type: "graph"
+      targets:
+        - expr: 'rate(external_commit_status_user_collisions_total[5m])'
+          legend: "Collisions per second"
+      description: "Rate of external commit status user collisions detected"
+      
+    - title: "Total Collisions by Project"
+      type: "table"
+      targets:
+        - expr: 'sum by (project_path) (external_commit_status_user_collisions_total)'
+          legend: "{{project_path}}"
+      description: "Projects with the highest number of collision events"
+      
+    - title: "Collisions by Protected Ref Status"
+      type: "pie"
+      targets:
+        - expr: 'sum by (ref_protected) (external_commit_status_user_collisions_total)'
+          legend: "Protected: {{ref_protected}}"
+      description: "Distribution of collisions between protected and unprotected refs"
+      
+    - title: "Collision Frequency Distribution"
+      type: "histogram"
+      targets:
+        - expr: 'histogram_quantile(0.50, rate(external_commit_status_user_collisions_total[5m]))'
+          legend: "50th percentile"
+        - expr: 'histogram_quantile(0.95, rate(external_commit_status_user_collisions_total[5m]))'
+          legend: "95th percentile"
+        - expr: 'histogram_quantile(0.99, rate(external_commit_status_user_collisions_total[5m]))'
+          legend: "99th percentile"
+      description: "Distribution of collision rates across time periods"
+      
+    - title: "Top Affected Projects (Last 24h)"
+      type: "table"
+      targets:
+        - expr: 'topk(10, increase(external_commit_status_user_collisions_total[24h]))'
+          legend: "{{project_path}}"
+      description: "Projects with most collisions in the last 24 hours"
+      
+    - title: "Collision Trend (7 days)"
+      type: "graph"
+      targets:
+        - expr: 'increase(external_commit_status_user_collisions_total[1d])'
+          legend: "Daily collisions"
+      description: "Daily collision count trend over the past week"
+
+  alerts:
+    - name: "HighCollisionRate"
+      condition: 'rate(external_commit_status_user_collisions_total[5m]) > 0.1'
+      duration: "5m"
+      severity: "warning"
+      description: "High rate of external commit status user collisions detected"
+      
+    - name: "CollisionSpike"
+      condition: 'increase(external_commit_status_user_collisions_total[1h]) > 100'
+      duration: "1m"
+      severity: "critical"
+      description: "Unusual spike in external commit status user collisions"
+
+  variables:
+    - name: "time_range"
+      type: "interval"
+      options: ["5m", "15m", "1h", "6h", "24h", "7d"]
+      default: "1h"
+      
+    - name: "project_filter"
+      type: "query"
+      query: 'label_values(external_commit_status_user_collisions_total, project_path)'
+      multi: true
+      include_all: true
+
+refresh: "30s"
+time_range: "1h"
\ No newline at end of file
diff --git a/config/prometheus/external_commit_status_metrics.yml b/config/prometheus/external_commit_status_metrics.yml
new file mode 100644
index 0000000000000000000000000000000000000000..720751aa1e0bf8f57fdbd2cb6b33fd5e5f18293e
--- /dev/null
+++ b/config/prometheus/external_commit_status_metrics.yml
@@ -0,0 +1,131 @@
+# External Commit Status Metrics Configuration
+# Defines the metrics collection and alerting rules for external commit status collision detection
+
+metrics:
+  external_commit_status_user_collisions_total:
+    type: counter
+    description: "Total number of external commit status user collisions detected"
+    labels:
+      - project_path
+      - ref_protected
+    help: |
+      This metric tracks when multiple users attempt to post status updates for the same
+      commit/ref/name combination, which can lead to duplicate external jobs in pipelines.
+      
+      Labels:
+      - project_path: Full path of the affected project (e.g., "gitlab-org/gitlab")
+      - ref_protected: Whether the ref is protected ("true" or "false")
+      
+      Use this metric to:
+      1. Identify projects most affected by the collision issue
+      2. Understand the scope of the problem across GitLab.com
+      3. Monitor the effectiveness of any fixes implemented
+      4. Determine if protected refs have different collision patterns
+
+recording_rules:
+  # Daily collision counts by project
+  - record: external_commit_status_collisions:daily_by_project
+    expr: increase(external_commit_status_user_collisions_total[1d])
+    labels:
+      interval: "1d"
+      
+  # Hourly collision rates
+  - record: external_commit_status_collisions:rate_5m
+    expr: rate(external_commit_status_user_collisions_total[5m])
+    labels:
+      interval: "5m"
+      
+  # Top 10 affected projects (last 24h)
+  - record: external_commit_status_collisions:top_projects_24h
+    expr: topk(10, increase(external_commit_status_user_collisions_total[24h]))
+    labels:
+      interval: "24h"
+      
+  # Protected vs unprotected ref collision ratio
+  - record: external_commit_status_collisions:protected_ratio
+    expr: |
+      sum(external_commit_status_user_collisions_total{ref_protected="true"}) /
+      sum(external_commit_status_user_collisions_total)
+    labels:
+      metric_type: "ratio"
+
+alerting_rules:
+  # Warning: Sustained high collision rate
+  - alert: ExternalCommitStatusHighCollisionRate
+    expr: rate(external_commit_status_user_collisions_total[5m]) > 0.05
+    for: 10m
+    labels:
+      severity: warning
+      team: pipeline-execution
+      component: external-jobs
+    annotations:
+      summary: "High rate of external commit status user collisions"
+      description: |
+        The rate of external commit status user collisions is {{ $value }} per second,
+        which is above the warning threshold of 0.05/sec.
+        
+        This indicates multiple users are frequently posting status updates for the same
+        commit/ref/name combinations, potentially causing duplicate external jobs.
+        
+        Check the dashboard for affected projects and consider implementing the fix
+        if the collision rate remains high.
+      
+  # Critical: Collision spike indicating potential issue
+  - alert: ExternalCommitStatusCollisionSpike
+    expr: increase(external_commit_status_user_collisions_total[1h]) > 50
+    for: 5m
+    labels:
+      severity: critical
+      team: pipeline-execution
+      component: external-jobs
+    annotations:
+      summary: "Spike in external commit status user collisions"
+      description: |
+        There have been {{ $value }} external commit status user collisions in the last hour,
+        which is significantly above normal levels.
+        
+        This could indicate:
+        1. A misconfigured external CI integration
+        2. A bug in external job handling
+        3. Unusual usage patterns
+        
+        Investigate immediately and consider temporarily disabling problematic integrations.
+        
+  # Info: New project experiencing collisions
+  - alert: ExternalCommitStatusNewProjectCollisions
+    expr: |
+      increase(external_commit_status_user_collisions_total[24h]) > 0
+      and
+      increase(external_commit_status_user_collisions_total[7d] offset 7d) == 0
+    for: 1h
+    labels:
+      severity: info
+      team: pipeline-execution
+      component: external-jobs
+    annotations:
+      summary: "New project experiencing external commit status collisions"
+      description: |
+        Project {{ $labels.project_path }} has started experiencing external commit status
+        user collisions for the first time in the past week.
+        
+        This could indicate:
+        1. New external CI integration setup
+        2. Changes in integration configuration
+        3. New usage patterns
+        
+        Monitor the project to understand if this is expected behavior.
+
+# Data retention and aggregation settings
+retention:
+  raw_metrics: "30d"  # Keep raw collision events for 30 days
+  daily_aggregates: "1y"  # Keep daily summaries for 1 year
+  
+# Export settings for analysis
+export:
+  enabled: true
+  formats: ["prometheus", "json", "csv"]
+  schedule: "0 2 * * *"  # Daily at 2 AM UTC
+  destinations:
+    - type: "s3"
+      bucket: "gitlab-metrics-exports"
+      prefix: "external-commit-status-collisions/"
\ No newline at end of file
diff --git a/doc/api/external_commit_status_data_collection.md b/doc/api/external_commit_status_data_collection.md
new file mode 100644
index 0000000000000000000000000000000000000000..ebf53a44f422f85ac5411565d6031c8228186006
--- /dev/null
+++ b/doc/api/external_commit_status_data_collection.md
@@ -0,0 +1,176 @@
+# External Commit Status Data Collection
+
+This document describes the data collection and instrumentation added to the Commit Status API
+to understand usage patterns related to external job creation from multiple users.
+
+## Overview
+
+As part of addressing [issue #556556](https://gitlab.com/gitlab-org/gitlab/-/issues/556556), 
+we have implemented comprehensive instrumentation to detect and analyze cases where multiple 
+users post status updates for the same commit. This data collection phase (Phase 1) will 
+inform decisions about how to handle duplicate external job scenarios.
+
+## What Data is Collected
+
+### Collision Detection
+
+A "collision" is detected when:
+1. A user attempts to create a commit status via the API
+2. There is already a running or pending status for the same:
+   - Project
+   - Commit SHA
+   - Git reference (branch/tag)  
+   - Status name
+   - But created by a **different user**
+
+### Logged Information
+
+When a collision is detected, the following structured log entry is created:
+
+```json
+{
+  "class": "Ci::CreateCommitStatusService",
+  "event": "external_commit_status_user_collision",
+  "project_id": 12345,
+  "pipeline_id": 67890,
+  "commit_sha": "abc123...",
+  "ref": "main",
+  "status_name": "buildkite-test",
+  "current_user_id": 111,
+  "existing_user_ids": [222, 333],
+  "existing_status_count": 2,
+  "subscription_plan": "premium"
+}
+```
+
+### Prometheus Metrics
+
+A counter metric is incremented for each collision:
+
+```
+external_commit_status_user_collisions_total{project_path="org/project", ref_protected="false"}
+```
+
+**Labels:**
+- `project_path`: Full path of the affected project
+- `ref_protected`: Whether the git reference is protected ("true" or "false")
+
+## Privacy and Security
+
+### What is NOT logged:
+- Status descriptions or target URLs
+- Commit messages or file contents
+- User names or email addresses (only user IDs)
+- Any sensitive project data
+
+### What IS logged:
+- Numeric IDs (project, user, pipeline)
+- Git references and commit SHAs (already public in most cases)
+- Status names (typically generic like "test", "build", "deploy")
+- Subscription plan level (for usage pattern analysis)
+
+### Data Retention:
+- Raw logs: 30 days
+- Aggregated metrics: 1 year
+- Exported analysis data: As needed for decision making
+
+## API Behavior
+
+**Important:** This instrumentation does **not** change API behavior in any way.
+
+- All commit status creation requests continue to work exactly as before
+- No new parameters are required or accepted
+- Response format and status codes remain unchanged
+- Performance impact is minimal (single additional database query)
+
+## Use Cases Being Analyzed
+
+### Buildkite Integration
+The primary use case driving this analysis is Buildkite's GitLab integration, where:
+1. Multiple Buildkite agents may use different user tokens
+2. Agents post status updates for the same build/commit
+3. This creates duplicate external jobs in GitLab pipelines
+
+### Other External CI Systems
+Similar patterns may occur with:
+- Jenkins integrations
+- Custom CI/CD systems
+- Third-party testing services
+- Manual API usage
+
+## Monitoring and Alerting
+
+### Dashboard Metrics
+- Collision rate over time
+- Most affected projects
+- Protected vs unprotected ref patterns
+- Geographic/temporal distribution
+
+### Alerts
+- **Warning:** Sustained high collision rate (>0.05/sec for 10 minutes)
+- **Critical:** Collision spike (>50 collisions in 1 hour)
+- **Info:** New projects experiencing collisions
+
+## Analysis Goals
+
+The data collection aims to answer:
+
+1. **Volume:** How frequently do collisions occur across GitLab.com?
+2. **Scope:** Which projects and integrations are most affected?
+3. **Patterns:** Are there legitimate use cases for multiple users creating separate statuses?
+4. **Impact:** How does this affect pipeline completion and user experience?
+5. **Timing:** Are collisions clustered around specific times or events?
+
+## Next Steps (Phase 2)
+
+Based on the collected data, we will decide between:
+
+### Option A: Direct Fix (Low Usage)
+If collisions are rare (<0.1% of status creations):
+- Remove user scoping from external status lookup
+- Implement direct fix to prevent duplicates
+
+### Option B: Backward Compatible Fix (Moderate Usage)  
+If collisions are common but legitimate use cases exist:
+- Add optional API parameter for collision handling
+- Provide migration path for affected integrations
+- Maintain backward compatibility
+
+### Option C: No Change (High Legitimate Usage)
+If analysis shows collisions are intentional and beneficial:
+- Keep current behavior
+- Improve documentation and tooling instead
+
+## Integration Impact
+
+### For Buildkite Users
+- No immediate changes required
+- Monitor collision metrics for your projects
+- Prepare for potential future API updates
+
+### For Other Integrations
+- Review your external CI setup if you see collision alerts
+- Consider consolidating to single user tokens if appropriate
+- Contact support if you have questions about collision patterns
+
+## Timeline
+
+- **Phase 1 (Data Collection):** 2-4 weeks of instrumentation
+- **Analysis Period:** 1-2 weeks to analyze collected data  
+- **Phase 2 (Implementation):** Based on analysis results
+- **Migration Period:** 4-8 weeks for affected integrations (if needed)
+
+## Support
+
+If you have questions about this data collection or notice unusual behavior:
+
+1. Check the [main issue](https://gitlab.com/gitlab-org/gitlab/-/issues/556556) for updates
+2. Review your project's collision metrics in the monitoring dashboard
+3. Contact GitLab support if you need assistance
+
+## Related Documentation
+
+- [Commit Status API](commit_statuses.md)
+- [External CI Integration Guide](../ci/external/index.md)
+- [Buildkite Integration](../ci/external/buildkite.md)
+- [Pipeline Troubleshooting](../ci/troubleshooting.md)
\ No newline at end of file
diff --git a/doc/ci/external/commit_status_collision_migration_guide.md b/doc/ci/external/commit_status_collision_migration_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..06db7197dda9759356fd2c6891775f5a42e034bd
--- /dev/null
+++ b/doc/ci/external/commit_status_collision_migration_guide.md
@@ -0,0 +1,481 @@
+# External Commit Status Collision Migration Guide
+
+This guide helps external CI integrations prepare for and migrate to the improved external commit 
+status handling that addresses user collision issues described in 
+[issue #556556](https://gitlab.com/gitlab-org/gitlab/-/issues/556556).
+
+## Overview
+
+GitLab is improving how external commit statuses are handled when multiple users post updates 
+for the same commit. This change primarily affects integrations like Buildkite, Jenkins, and 
+custom CI systems that may use different user tokens for the same build.
+
+## What's Changing
+
+### Current Behavior
+When different users post status updates for the same commit/ref/name combination:
+- Multiple separate external jobs are created
+- Each job is scoped to the user who created it
+- This can lead to duplicate statuses and incomplete pipelines
+
+### New Behavior (After Migration)
+Depending on the implementation chosen based on data analysis:
+- **Option A:** Single status per commit/ref/name, regardless of user
+- **Option B:** Configurable behavior with API parameter
+- **Option C:** Enhanced current behavior with better tooling
+
+## Impact Assessment
+
+### Check If You're Affected
+
+Your integration may be affected if:
+
+1. **Multiple User Tokens:** You use different GitLab user tokens for the same build/pipeline
+2. **Duplicate Statuses:** You've noticed duplicate external jobs in GitLab pipelines
+3. **Incomplete Pipelines:** Pipelines remain "running" due to pending external statuses
+4. **Buildkite Integration:** You use Buildkite's GitLab integration
+
+### Determine Your Usage Pattern
+
+Run this analysis to understand your current usage:
+
+```bash
+# Check for collision patterns in your projects
+curl -H "PRIVATE-TOKEN: your-token" \
+  "https://gitlab.com/api/v4/projects/YOUR_PROJECT_ID/pipelines?per_page=100" | \
+  jq '.[] | select(.status == "running") | .id' | \
+  while read pipeline_id; do
+    echo "Pipeline $pipeline_id:"
+    curl -H "PRIVATE-TOKEN: your-token" \
+      "https://gitlab.com/api/v4/projects/YOUR_PROJECT_ID/pipelines/$pipeline_id/jobs" | \
+      jq '.[] | select(.stage == "external") | {name: .name, user: .user.username, status: .status}'
+  done
+```
+
+Look for:
+- Multiple jobs with the same name but different users
+- Jobs stuck in "pending" status
+- Patterns of duplicate external statuses
+
+## Migration Scenarios
+
+### Scenario 1: Buildkite Integration
+
+**Current Setup:**
+```yaml
+# buildkite pipeline.yml
+steps:
+  - label: "Test"
+    command: "npm test"
+    plugins:
+      - gitlab-integration:
+          project_id: 12345
+          token: "${BUILDKITE_GITLAB_TOKEN}"  # Different per agent
+```
+
+**Issue:** Different Buildkite agents use different user tokens, creating duplicate statuses.
+
+#### Migration Option A: Direct Fix (No Changes Required)
+If the direct fix is implemented, no changes are needed. The system will automatically 
+consolidate statuses from different users.
+
+**Benefits:**
+- No integration changes required
+- Immediate improvement in pipeline behavior
+- Reduced duplicate statuses
+
+**Timeline:** Automatic with GitLab update
+
+#### Migration Option B: API Parameter (Recommended)
+Update your integration to use the new `unique_per_commit` parameter:
+
+```bash
+# Old API call
+curl -X POST "https://gitlab.com/api/v4/projects/12345/statuses/abc123" \
+  -H "PRIVATE-TOKEN: ${BUILDKITE_GITLAB_TOKEN}" \
+  -d "state=pending&name=test&ref=main"
+
+# New API call (prevents duplicates)
+curl -X POST "https://gitlab.com/api/v4/projects/12345/statuses/abc123" \
+  -H "PRIVATE-TOKEN: ${BUILDKITE_GITLAB_TOKEN}" \
+  -d "state=pending&name=test&ref=main&unique_per_commit=true"
+```
+
+**Buildkite Plugin Update:**
+```yaml
+# Updated buildkite pipeline.yml
+steps:
+  - label: "Test"
+    command: "npm test"
+    plugins:
+      - gitlab-integration:
+          project_id: 12345
+          token: "${BUILDKITE_GITLAB_TOKEN}"
+          unique_per_commit: true  # New parameter
+```
+
+**Migration Steps:**
+1. Update Buildkite plugin to latest version (when available)
+2. Add `unique_per_commit: true` to your pipeline configuration
+3. Test with a few builds to verify behavior
+4. Roll out to all pipelines
+
+**Timeline:** 2-4 weeks after API parameter availability
+
+### Scenario 2: Jenkins Integration
+
+**Current Setup:**
+```groovy
+// Jenkinsfile
+pipeline {
+    agent any
+    stages {
+        stage('Test') {
+            steps {
+                script {
+                    // Different Jenkins nodes may use different tokens
+                    gitlabCommitStatus(name: 'jenkins-test') {
+                        sh 'npm test'
+                    }
+                }
+            }
+        }
+    }
+}
+```
+
+**Issue:** Jenkins nodes with different GitLab tokens create duplicate statuses.
+
+#### Migration Approaches
+
+**Option 1: Consolidate Tokens**
+Use a single service account token across all Jenkins nodes:
+
+```groovy
+pipeline {
+    agent any
+    environment {
+        GITLAB_TOKEN = credentials('gitlab-service-account-token')  // Single token
+    }
+    stages {
+        stage('Test') {
+            steps {
+                gitlabCommitStatus(name: 'jenkins-test', gitLabConnection: 'gitlab-service-account') {
+                    sh 'npm test'
+                }
+            }
+        }
+    }
+}
+```
+
+**Option 2: Use API Parameter (if available)**
+```groovy
+// When unique_per_commit parameter is available
+gitlabCommitStatus(name: 'jenkins-test', uniquePerCommit: true) {
+    sh 'npm test'
+}
+```
+
+**Migration Steps:**
+1. Create dedicated GitLab service account for Jenkins
+2. Update Jenkins GitLab plugin configuration
+3. Test with sample pipelines
+4. Update all Jenkinsfiles to use new configuration
+5. Remove old user-specific tokens
+
+**Timeline:** 3-6 weeks
+
+### Scenario 3: Custom CI Integration
+
+**Current Setup:**
+```python
+# Custom CI system
+import requests
+
+def post_gitlab_status(project_id, commit_sha, status, name, user_token):
+    url = f"https://gitlab.com/api/v4/projects/{project_id}/statuses/{commit_sha}"
+    headers = {"PRIVATE-TOKEN": user_token}
+    data = {
+        "state": status,
+        "name": name,
+        "ref": "main"
+    }
+    response = requests.post(url, headers=headers, data=data)
+    return response
+
+# Different workers use different tokens
+post_gitlab_status(12345, "abc123", "pending", "custom-test", worker_token)
+```
+
+**Issue:** Different workers/processes use different user tokens.
+
+#### Migration Options
+
+**Option 1: Service Account Token**
+```python
+# Use single service account token
+GITLAB_SERVICE_TOKEN = "your-service-account-token"
+
+def post_gitlab_status(project_id, commit_sha, status, name):
+    url = f"https://gitlab.com/api/v4/projects/{project_id}/statuses/{commit_sha}"
+    headers = {"PRIVATE-TOKEN": GITLAB_SERVICE_TOKEN}
+    data = {
+        "state": status,
+        "name": name,
+        "ref": "main"
+    }
+    response = requests.post(url, headers=headers, data=data)
+    return response
+```
+
+**Option 2: API Parameter (if available)**
+```python
+def post_gitlab_status(project_id, commit_sha, status, name, user_token):
+    url = f"https://gitlab.com/api/v4/projects/{project_id}/statuses/{commit_sha}"
+    headers = {"PRIVATE-TOKEN": user_token}
+    data = {
+        "state": status,
+        "name": name,
+        "ref": "main",
+        "unique_per_commit": True  # Prevent duplicates
+    }
+    response = requests.post(url, headers=headers, data=data)
+    return response
+```
+
+**Option 3: Status Consolidation**
+```python
+def post_gitlab_status_with_consolidation(project_id, commit_sha, status, name, user_token):
+    # Check for existing status first
+    existing_status = get_existing_status(project_id, commit_sha, name)
+    
+    if existing_status and existing_status['status'] != status:
+        # Update existing status instead of creating new one
+        update_gitlab_status(project_id, existing_status['id'], status, user_token)
+    else:
+        # Create new status
+        post_gitlab_status(project_id, commit_sha, status, name, user_token)
+```
+
+## Migration Timeline
+
+### Phase 1: Preparation (Before Changes)
+- **Week 1-2:** Assess your current integration
+- **Week 3-4:** Plan migration approach
+- **Week 5-6:** Prepare updated integration code
+- **Week 7-8:** Test in staging/development environment
+
+### Phase 2: Migration (After GitLab Changes)
+- **Week 1:** Deploy updated integration to small subset
+- **Week 2-3:** Monitor for issues and adjust
+- **Week 4-6:** Gradual rollout to all projects
+- **Week 7-8:** Complete migration and cleanup
+
+### Phase 3: Validation (Post-Migration)
+- **Week 1-2:** Verify collision reduction
+- **Week 3-4:** Monitor pipeline completion rates
+- **Week 5-8:** Long-term stability monitoring
+
+## Testing Your Migration
+
+### Pre-Migration Testing
+
+**Test Environment Setup:**
+1. Create test GitLab project
+2. Set up multiple user tokens
+3. Simulate your current integration behavior
+4. Document baseline collision patterns
+
+**Test Scenarios:**
+```bash
+# Test 1: Multiple users posting same status
+curl -X POST "https://gitlab.com/api/v4/projects/TEST_PROJECT/statuses/TEST_SHA" \
+  -H "PRIVATE-TOKEN: user1-token" \
+  -d "state=pending&name=test&ref=main"
+
+curl -X POST "https://gitlab.com/api/v4/projects/TEST_PROJECT/statuses/TEST_SHA" \
+  -H "PRIVATE-TOKEN: user2-token" \
+  -d "state=running&name=test&ref=main"
+
+# Check results
+curl -H "PRIVATE-TOKEN: user1-token" \
+  "https://gitlab.com/api/v4/projects/TEST_PROJECT/repository/commits/TEST_SHA/statuses"
+```
+
+### Post-Migration Testing
+
+**Validation Checklist:**
+- [ ] No duplicate statuses created for same commit/ref/name
+- [ ] Status updates work correctly
+- [ ] Pipeline completion works as expected
+- [ ] Integration performance maintained
+- [ ] Error handling works properly
+
+**Automated Testing:**
+```python
+def test_collision_prevention():
+    # Post status from user 1
+    response1 = post_status(project_id, commit_sha, "pending", "test", user1_token)
+    assert response1.status_code == 201
+    
+    # Post status from user 2 (should update, not duplicate)
+    response2 = post_status(project_id, commit_sha, "success", "test", user2_token)
+    assert response2.status_code in [200, 201]
+    
+    # Verify only one status exists
+    statuses = get_commit_statuses(project_id, commit_sha)
+    test_statuses = [s for s in statuses if s['name'] == 'test']
+    assert len(test_statuses) == 1
+    assert test_statuses[0]['status'] == 'success'
+```
+
+## Troubleshooting
+
+### Common Issues
+
+**Issue 1: Integration Breaks After Migration**
+```
+Error: 400 Bad Request - Invalid parameter: unique_per_commit
+```
+
+**Solution:** Your GitLab instance may not support the new parameter yet. Either:
+- Wait for GitLab update
+- Use service account token approach instead
+- Contact GitLab support for timeline
+
+**Issue 2: Statuses Not Updating**
+```
+Status remains "pending" even after posting "success"
+```
+
+**Solution:** Check if you're using the correct commit SHA and status name:
+```bash
+# Verify commit SHA
+git rev-parse HEAD
+
+# Check existing statuses
+curl -H "PRIVATE-TOKEN: your-token" \
+  "https://gitlab.com/api/v4/projects/PROJECT_ID/repository/commits/COMMIT_SHA/statuses"
+```
+
+**Issue 3: Permission Errors**
+```
+Error: 403 Forbidden - Insufficient permissions
+```
+
+**Solution:** Ensure your service account token has appropriate permissions:
+- Developer role or higher on the project
+- API access enabled
+- Token not expired
+
+### Getting Help
+
+**GitLab Support:**
+- Create support ticket with integration details
+- Include example API calls and responses
+- Mention this migration guide
+
+**Community Resources:**
+- [GitLab Community Forum](https://forum.gitlab.com/)
+- [External CI Integration Documentation](../index.md)
+- [API Documentation](../../api/commit_statuses.md)
+
+**Integration-Specific Help:**
+- **Buildkite:** [Buildkite GitLab Integration Docs](https://buildkite.com/docs/integrations/gitlab)
+- **Jenkins:** [GitLab Plugin Documentation](https://plugins.jenkins.io/gitlab-plugin/)
+- **Custom:** [GitLab API Documentation](../../api/README.md)
+
+## Best Practices
+
+### Token Management
+
+**Use Service Accounts:**
+- Create dedicated service accounts for CI integrations
+- Use descriptive names (e.g., "buildkite-integration")
+- Rotate tokens regularly
+- Limit permissions to minimum required
+
+**Token Security:**
+```bash
+# Store tokens securely
+export GITLAB_TOKEN=$(vault kv get -field=token secret/gitlab/ci-token)
+
+# Don't log tokens
+curl -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}" ... 2>/dev/null
+```
+
+### Status Naming
+
+**Consistent Naming:**
+```python
+# Good: Consistent, descriptive names
+status_names = {
+    "unit_tests": "unit-tests",
+    "integration_tests": "integration-tests", 
+    "security_scan": "security-scan"
+}
+
+# Avoid: Inconsistent or user-specific names
+# "test-user1", "test-user2", "test_john_doe"
+```
+
+### Error Handling
+
+**Robust Error Handling:**
+```python
+def post_status_with_retry(project_id, commit_sha, status, name, max_retries=3):
+    for attempt in range(max_retries):
+        try:
+            response = post_gitlab_status(project_id, commit_sha, status, name)
+            if response.status_code in [200, 201]:
+                return response
+            elif response.status_code == 400:
+                # Don't retry client errors
+                break
+        except requests.RequestException as e:
+            if attempt == max_retries - 1:
+                raise
+            time.sleep(2 ** attempt)  # Exponential backoff
+    
+    raise Exception(f"Failed to post status after {max_retries} attempts")
+```
+
+### Monitoring
+
+**Track Integration Health:**
+```python
+import logging
+
+def post_status_with_monitoring(project_id, commit_sha, status, name):
+    start_time = time.time()
+    try:
+        response = post_gitlab_status(project_id, commit_sha, status, name)
+        duration = time.time() - start_time
+        
+        logging.info(f"GitLab status posted successfully", extra={
+            "project_id": project_id,
+            "status": status,
+            "name": name,
+            "duration": duration,
+            "response_code": response.status_code
+        })
+        return response
+    except Exception as e:
+        logging.error(f"Failed to post GitLab status", extra={
+            "project_id": project_id,
+            "status": status,
+            "name": name,
+            "error": str(e)
+        })
+        raise
+```
+
+## Conclusion
+
+This migration guide provides comprehensive information for updating your external CI integration
+to work optimally with GitLab's improved external commit status handling. The key is to assess
+your current usage, choose the appropriate migration path, and test thoroughly before full deployment.
+
+For questions or assistance with your specific integration, please refer to the support resources
+listed above or create a GitLab support ticket with details about your use case.
\ No newline at end of file
diff --git a/doc/development/external_commit_status_collision_fix_plan.md b/doc/development/external_commit_status_collision_fix_plan.md
new file mode 100644
index 0000000000000000000000000000000000000000..b0cabc66478e701f77306c20523b937de0d00d26
--- /dev/null
+++ b/doc/development/external_commit_status_collision_fix_plan.md
@@ -0,0 +1,410 @@
+# External Commit Status User Collision Fix - Implementation Plan
+
+This document outlines the comprehensive plan for addressing external commit status user collisions
+as described in [issue #556556](https://gitlab.com/gitlab-org/gitlab/-/issues/556556).
+
+## Problem Statement
+
+When multiple users post status updates for the same commit/ref/name combination (common with 
+Buildkite and other external CI integrations), the current implementation creates separate 
+external jobs instead of updating the existing one. This leads to:
+
+1. Duplicate status entries in pipelines
+2. Pipelines that never complete (pending statuses remain)
+3. Confusion in the UI with multiple statuses for the same job
+4. Potential performance issues with excessive external jobs
+
+## Root Cause Analysis
+
+The issue stems from the `external_commit_status_scope` method in `Ci::CreateCommitStatusService`:
+
+```ruby
+def external_commit_status_scope(pipeline)
+  scope = ::GenericCommitStatus
+    .running_or_pending
+    .for_project(project.id)
+    .in_pipelines(pipeline)
+    .in_partition(pipeline.partition_id)
+    .for_ref(ref)
+    .by_name(name)
+    .for_user(current_user)  # <-- This line causes the issue
+  scope = scope.ref_protected if project.protected_for?(ref)
+  scope
+end
+```
+
+The `.for_user(current_user)` scoping means that when a different user posts a status update,
+the system doesn't find the existing status and creates a new one instead.
+
+## Two-Phase Implementation Approach
+
+### Phase 1: Data Collection and Analysis ✅ COMPLETED
+
+**Objective:** Understand the scope and impact of the collision issue.
+
+**Implementation:**
+- [x] Add collision detection instrumentation to `find_or_build_external_commit_status`
+- [x] Implement structured logging for collision events
+- [x] Add Prometheus metrics counter for collision tracking
+- [x] Create comprehensive test coverage
+- [x] Set up monitoring dashboards and alerts
+- [x] Update API documentation
+
+**Duration:** 2-4 weeks of data collection
+
+**Success Criteria:**
+- Instrumentation deployed to production
+- Data collection running without performance impact
+- Monitoring dashboards operational
+- Initial collision patterns identified
+
+### Phase 2: Decision Making and Implementation
+
+**Objective:** Implement the appropriate fix based on collected data.
+
+The implementation path depends on the analysis results:
+
+## Decision Tree
+
+### Scenario A: Low Collision Frequency (<0.1% of external status creations)
+
+**Interpretation:** Collisions are rare edge cases, likely due to misconfiguration or unusual usage.
+
+**Implementation: Direct Fix**
+
+```ruby
+def external_commit_status_scope(pipeline)
+  scope = ::GenericCommitStatus
+    .running_or_pending
+    .for_project(project.id)
+    .in_pipelines(pipeline)
+    .in_partition(pipeline.partition_id)
+    .for_ref(ref)
+    .by_name(name)
+    # Remove .for_user(current_user) to prevent duplicates
+  scope = scope.ref_protected if project.protected_for?(ref)
+  scope
+end
+```
+
+**Migration Steps:**
+1. Deploy fix with feature flag (disabled by default)
+2. Enable for small subset of projects
+3. Monitor for issues
+4. Gradual rollout to all projects
+5. Remove feature flag after 2 weeks
+
+**Timeline:** 2-3 weeks
+
+**Risk:** Low - affects few users, clear improvement
+
+---
+
+### Scenario B: Moderate Collision Frequency (0.1% - 1% of external status creations)
+
+**Interpretation:** Collisions are common enough to matter, but may include legitimate use cases.
+
+**Implementation: Backward Compatible API Parameter**
+
+Add new optional parameter to the Commit Status API:
+
+```ruby
+# In lib/api/commit_statuses.rb
+optional :unique_per_commit, type: Boolean, 
+         desc: 'Ensure only one status exists per commit/ref/name combination, regardless of user', 
+         default: false
+```
+
+```ruby
+# In app/services/ci/create_commit_status_service.rb
+def external_commit_status_scope(pipeline)
+  scope = ::GenericCommitStatus
+    .running_or_pending
+    .for_project(project.id)
+    .in_pipelines(pipeline)
+    .in_partition(pipeline.partition_id)
+    .for_ref(ref)
+    .by_name(name)
+  
+  # Only scope by user if unique_per_commit is false (backward compatibility)
+  unless params[:unique_per_commit]
+    scope = scope.for_user(current_user)
+  end
+  
+  scope = scope.ref_protected if project.protected_for?(ref)
+  scope
+end
+```
+
+**Migration Steps:**
+1. Deploy API parameter (default: false for backward compatibility)
+2. Update documentation with migration guide
+3. Work with Buildkite team to adopt new parameter
+4. Provide migration timeline (6 months)
+5. Consider changing default to true in future major version
+
+**Timeline:** 4-6 weeks implementation + 6 months migration period
+
+**Risk:** Medium - requires coordination with external integrations
+
+---
+
+### Scenario C: High Collision Frequency (>1% of external status creations)
+
+**Interpretation:** Collisions are very common, indicating widespread legitimate use cases.
+
+**Implementation: Enhanced Current Behavior**
+
+Instead of changing the core behavior, improve the experience:
+
+1. **Better Documentation:**
+   - Clear guidance on when multiple users should create separate statuses
+   - Best practices for external CI integrations
+   - Troubleshooting guide for duplicate status issues
+
+2. **UI Improvements:**
+   - Group related statuses in pipeline view
+   - Show "multiple users" indicator
+   - Provide status consolidation tools
+
+3. **API Enhancements:**
+   - Add status querying by multiple users
+   - Provide status consolidation endpoints
+   - Better error messages for common issues
+
+**Timeline:** 6-8 weeks
+
+**Risk:** Low - no breaking changes, improves existing experience
+
+---
+
+### Scenario D: Mixed Patterns (Varies by project type/size)
+
+**Interpretation:** Different projects have different legitimate needs.
+
+**Implementation: Project-Level Configuration**
+
+Add project setting to control collision behavior:
+
+```ruby
+# Migration
+class AddExternalStatusCollisionHandlingToProjects < ActiveRecord::Migration[7.0]
+  def change
+    add_column :projects, :external_status_collision_handling, :integer, default: 0
+  end
+end
+
+# Model
+class Project
+  enum external_status_collision_handling: {
+    allow_duplicates: 0,    # Current behavior (default)
+    prevent_duplicates: 1,  # New behavior
+    user_choice: 2          # Let API caller decide per request
+  }
+end
+```
+
+**Migration Steps:**
+1. Add project setting with safe default
+2. Provide UI for project owners to configure
+3. Update API to respect project setting
+4. Gradual migration based on project analysis
+5. Provide recommendations based on project patterns
+
+**Timeline:** 8-10 weeks
+
+**Risk:** Medium - complex implementation, requires careful testing
+
+## Implementation Details
+
+### Code Changes Required
+
+**Core Service Changes:**
+- `app/services/ci/create_commit_status_service.rb`
+- `lib/api/commit_statuses.rb` (if API changes needed)
+- Database migrations (if project settings needed)
+
+**Test Updates:**
+- Update existing tests for new behavior
+- Add comprehensive collision scenario tests
+- Integration tests with various external CI patterns
+
+**Documentation Updates:**
+- API documentation
+- External CI integration guides
+- Migration guides for affected integrations
+- Troubleshooting documentation
+
+### Feature Flag Strategy
+
+All implementations will use feature flags for safe rollout:
+
+```ruby
+# Example feature flag usage
+if Feature.enabled?(:prevent_external_status_collisions, project)
+  # New behavior
+else
+  # Current behavior (fallback)
+end
+```
+
+**Rollout Phases:**
+1. Internal GitLab projects (1 week)
+2. Volunteer beta projects (1 week)  
+3. Gradual percentage rollout (2-4 weeks)
+4. Full rollout
+5. Remove feature flag (2 weeks after full rollout)
+
+### Monitoring and Rollback
+
+**Success Metrics:**
+- Reduction in collision events
+- No increase in API errors
+- Stable pipeline completion rates
+- Positive feedback from affected integrations
+
+**Rollback Triggers:**
+- Increase in API error rates >5%
+- Pipeline completion rate drops >2%
+- Critical issues reported by major integrations
+- Performance degradation >10%
+
+**Rollback Process:**
+1. Disable feature flag immediately
+2. Investigate root cause
+3. Fix issues in development
+4. Re-deploy with fixes
+5. Resume gradual rollout
+
+## Integration Migration Guide
+
+### For Buildkite Integration
+
+**Current State:**
+Multiple Buildkite agents use different user tokens, creating duplicate statuses.
+
+**Recommended Migration (Scenario B):**
+```bash
+# Old API call
+curl -X POST "https://gitlab.com/api/v4/projects/123/statuses/abc123" \
+  -H "PRIVATE-TOKEN: user-token" \
+  -d "state=pending&name=test&ref=main"
+
+# New API call (prevents duplicates)
+curl -X POST "https://gitlab.com/api/v4/projects/123/statuses/abc123" \
+  -H "PRIVATE-TOKEN: user-token" \
+  -d "state=pending&name=test&ref=main&unique_per_commit=true"
+```
+
+**Migration Timeline:**
+- Month 1: API parameter available, documentation updated
+- Month 2-3: Buildkite team implements support
+- Month 4-5: Gradual rollout to Buildkite users
+- Month 6: Full migration complete
+
+### For Custom Integrations
+
+**Assessment Questions:**
+1. Do you intentionally create multiple statuses per commit from different users?
+2. Are your duplicate statuses causing pipeline completion issues?
+3. Would consolidating statuses improve your workflow?
+
+**Migration Paths:**
+- **Scenario A/B:** Update integration to use new API behavior
+- **Scenario C:** No changes needed, improved documentation available
+- **Scenario D:** Configure project setting based on your needs
+
+## Risk Assessment
+
+### Technical Risks
+
+**High Risk:**
+- Breaking existing integrations that depend on current behavior
+- Performance impact from additional database queries
+- Race conditions in concurrent status creation
+
+**Mitigation:**
+- Comprehensive testing with real-world scenarios
+- Feature flags for safe rollout
+- Performance monitoring and optimization
+- Exclusive locking for concurrent requests
+
+**Medium Risk:**
+- User confusion during migration period
+- Incomplete migration by external integrations
+- Edge cases not covered in testing
+
+**Mitigation:**
+- Clear communication and documentation
+- Extended migration timeline
+- Comprehensive test coverage
+- Beta testing with volunteer projects
+
+**Low Risk:**
+- Monitoring overhead from instrumentation
+- Storage requirements for collision data
+
+**Mitigation:**
+- Efficient metric collection
+- Data retention policies
+- Regular cleanup of old data
+
+### Business Risks
+
+**Impact on Integrations:**
+- Buildkite: High impact, requires coordination
+- Jenkins: Medium impact, varies by setup
+- Custom integrations: Variable impact
+
+**User Experience:**
+- Positive: Fewer duplicate statuses, cleaner pipelines
+- Negative: Potential confusion during migration
+
+**Support Load:**
+- Initial increase during migration period
+- Long-term decrease due to fewer duplicate status issues
+
+## Success Criteria
+
+### Phase 1 (Data Collection) ✅
+- [x] Instrumentation deployed without issues
+- [x] Collision data being collected
+- [x] Monitoring dashboards operational
+- [x] No performance impact detected
+
+### Phase 2 (Implementation)
+- [ ] Fix deployed based on data analysis
+- [ ] Collision rate reduced by >90% for affected projects
+- [ ] No increase in API error rates
+- [ ] Successful migration of major integrations (Buildkite)
+- [ ] Positive feedback from affected users
+- [ ] Documentation updated and comprehensive
+
+### Long-term Success
+- [ ] Sustained reduction in duplicate external job issues
+- [ ] Improved pipeline completion rates
+- [ ] Reduced support tickets related to external status problems
+- [ ] Successful adoption by external CI integrations
+
+## Timeline Summary
+
+| Phase | Duration | Key Milestones |
+|-------|----------|----------------|
+| Phase 1 (Complete) | 4 weeks | Data collection, monitoring setup |
+| Analysis | 1-2 weeks | Data analysis, decision making |
+| Phase 2 Implementation | 2-10 weeks | Depends on chosen scenario |
+| Migration Period | 0-6 months | Depends on chosen scenario |
+| Cleanup | 2-4 weeks | Remove feature flags, finalize docs |
+
+**Total Timeline:** 3-12 months depending on implementation path
+
+## Conclusion
+
+This comprehensive plan provides multiple implementation paths based on real usage data,
+ensuring that the chosen solution appropriately balances fixing the collision issue with
+maintaining compatibility for legitimate use cases. The phased approach with feature flags
+and monitoring ensures safe deployment and the ability to rollback if issues arise.
+
+The success of this initiative will significantly improve the external CI integration
+experience on GitLab, reducing confusion and pipeline completion issues while maintaining
+the flexibility that external integrations require.
\ No newline at end of file
diff --git a/doc/development/external_commit_status_success_criteria_rollback.md b/doc/development/external_commit_status_success_criteria_rollback.md
new file mode 100644
index 0000000000000000000000000000000000000000..6c217664573217ed96fa33eab06cddc97bcf0041
--- /dev/null
+++ b/doc/development/external_commit_status_success_criteria_rollback.md
@@ -0,0 +1,400 @@
+# External Commit Status Collision Fix - Success Criteria and Rollback Procedures
+
+This document defines the success criteria for evaluating the effectiveness of the external 
+commit status collision fix and provides detailed rollback procedures to ensure system stability.
+
+## Success Criteria
+
+### Phase 1: Data Collection (✅ COMPLETED)
+
+#### Primary Success Criteria
+- [x] **Instrumentation Deployment:** Successfully deployed collision detection code to production without errors
+- [x] **Data Collection Active:** Collision events being logged and metrics being collected
+- [x] **Monitoring Operational:** Dashboards and alerts functioning correctly
+- [x] **Performance Impact:** No measurable performance degradation (response time increase <5%)
+- [x] **System Stability:** No increase in error rates or system issues
+
+#### Secondary Success Criteria  
+- [x] **Test Coverage:** Comprehensive test suite covering all collision scenarios
+- [x] **Documentation Complete:** API documentation updated with data collection details
+- [x] **Monitoring Setup:** Prometheus metrics and Grafana dashboards configured
+- [x] **Alert Configuration:** Appropriate alerts for collision spikes and system issues
+
+### Phase 2: Implementation and Fix Deployment
+
+#### Critical Success Criteria (Must Achieve)
+
+**Functional Requirements:**
+- [ ] **Collision Reduction:** >90% reduction in collision events for affected projects
+- [ ] **API Stability:** No increase in API error rates (maintain <0.1% error rate)
+- [ ] **Pipeline Completion:** No degradation in pipeline completion rates
+- [ ] **Backward Compatibility:** Existing integrations continue to function without modification (unless opt-in changes)
+
+**Performance Requirements:**
+- [ ] **Response Time:** API response time increase <10% for commit status creation
+- [ ] **Database Performance:** No significant increase in database query time or load
+- [ ] **Memory Usage:** Service memory usage increase <5%
+- [ ] **Throughput:** Maintain current API throughput capacity
+
+**Reliability Requirements:**
+- [ ] **System Uptime:** No unplanned downtime related to the fix
+- [ ] **Error Handling:** Graceful handling of edge cases and error conditions
+- [ ] **Data Integrity:** No data loss or corruption during migration
+- [ ] **Rollback Capability:** Ability to rollback within 15 minutes if issues arise
+
+#### Important Success Criteria (Should Achieve)
+
+**User Experience:**
+- [ ] **UI Clarity:** Reduced confusion in pipeline UI due to duplicate statuses
+- [ ] **Integration Experience:** Positive feedback from major integrations (Buildkite, Jenkins)
+- [ ] **Support Tickets:** Reduction in support tickets related to duplicate external jobs
+- [ ] **Documentation Quality:** Clear migration guides and troubleshooting documentation
+
+**Operational Excellence:**
+- [ ] **Monitoring Coverage:** Comprehensive monitoring of fix effectiveness
+- [ ] **Alert Accuracy:** No false positive alerts, appropriate alert thresholds
+- [ ] **Deployment Process:** Smooth feature flag rollout without manual intervention
+- [ ] **Team Readiness:** Support and engineering teams prepared for migration issues
+
+#### Nice-to-Have Success Criteria (Could Achieve)
+
+**Advanced Features:**
+- [ ] **Analytics Dashboard:** Rich analytics showing collision patterns and fix effectiveness
+- [ ] **Self-Service Tools:** Tools for users to diagnose and fix their own collision issues
+- [ ] **Integration Recommendations:** Automated recommendations for integration improvements
+- [ ] **Performance Optimization:** Improved performance beyond baseline requirements
+
+### Measurement Methods
+
+#### Quantitative Metrics
+
+**Collision Metrics:**
+```prometheus
+# Before fix
+rate(external_commit_status_user_collisions_total[1h]) > 0.05
+
+# After fix (target)
+rate(external_commit_status_user_collisions_total[1h]) < 0.005
+```
+
+**API Performance:**
+```prometheus
+# Response time (target: <10% increase)
+histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{job="gitlab-api"}[5m]))
+
+# Error rate (target: maintain <0.1%)
+rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
+```
+
+**Pipeline Health:**
+```prometheus
+# Pipeline completion rate
+rate(ci_pipelines_total{status="success"}[1h]) / rate(ci_pipelines_total[1h])
+
+# External job success rate
+rate(ci_jobs_total{type="GenericCommitStatus",status="success"}[1h]) / 
+rate(ci_jobs_total{type="GenericCommitStatus"}[1h])
+```
+
+#### Qualitative Metrics
+
+**User Feedback:**
+- Integration partner satisfaction surveys
+- Support ticket sentiment analysis
+- Community forum feedback monitoring
+- Internal team feedback collection
+
+**Integration Health:**
+- Buildkite integration stability
+- Jenkins plugin compatibility
+- Custom integration migration success
+- Third-party CI service adoption
+
+### Success Evaluation Timeline
+
+| Timeframe | Evaluation Focus | Success Threshold |
+|-----------|------------------|-------------------|
+| 24 hours | System stability, immediate issues | No critical issues |
+| 1 week | Performance impact, basic functionality | All critical criteria met |
+| 2 weeks | User feedback, integration compatibility | 80% of important criteria met |
+| 1 month | Long-term stability, collision reduction | 90% of all criteria met |
+| 3 months | Integration migration, user adoption | Full success criteria achieved |
+
+## Rollback Procedures
+
+### Rollback Triggers
+
+#### Immediate Rollback (Within 15 minutes)
+
+**Critical Issues:**
+- API error rate increases >5% above baseline
+- System downtime or service unavailability
+- Data corruption or loss detected
+- Security vulnerability introduced
+- Performance degradation >25%
+
+**Trigger Conditions:**
+```prometheus
+# API error rate spike
+rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
+
+# Response time degradation
+histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 2.0
+
+# Memory usage spike
+process_resident_memory_bytes / process_virtual_memory_max_bytes > 0.9
+```
+
+#### Planned Rollback (Within 2 hours)
+
+**Significant Issues:**
+- Major integration breakage (Buildkite, Jenkins)
+- Widespread user complaints
+- Performance degradation 10-25%
+- Unexpected behavior in edge cases
+- Monitoring system failures
+
+#### Gradual Rollback (Within 24 hours)
+
+**Quality Issues:**
+- Success criteria not being met after 1 week
+- Negative user feedback trends
+- Integration migration difficulties
+- Documentation inadequacy
+- Support team overwhelm
+
+### Rollback Execution Procedures
+
+#### Step 1: Immediate Response (0-15 minutes)
+
+**Automated Rollback:**
+```bash
+# Disable feature flag immediately
+gitlab-rails runner "Feature.disable(:prevent_external_status_collisions)"
+
+# Verify rollback
+gitlab-rails runner "puts Feature.enabled?(:prevent_external_status_collisions)"
+```
+
+**Manual Verification:**
+1. Check API error rates return to baseline
+2. Verify commit status creation works normally
+3. Confirm monitoring alerts clear
+4. Test critical integration endpoints
+
+**Communication:**
+- Notify incident response team
+- Update status page if customer-facing
+- Alert engineering and support teams
+- Document rollback reason and time
+
+#### Step 2: Investigation and Analysis (15 minutes - 2 hours)
+
+**Root Cause Analysis:**
+1. Collect logs from affected time period
+2. Analyze error patterns and stack traces
+3. Review performance metrics and database queries
+4. Interview affected users or integration partners
+5. Identify specific failure mode
+
+**Impact Assessment:**
+- Number of affected projects/users
+- Duration of impact
+- Data integrity status
+- Integration partner impact
+- Customer escalations
+
+**Fix Planning:**
+- Determine if issue is fixable quickly
+- Assess need for code changes vs configuration
+- Plan testing approach for fix
+- Estimate time to resolution
+
+#### Step 3: Resolution and Re-deployment (2 hours - 1 week)
+
+**Fix Development:**
+```bash
+# Create hotfix branch
+git checkout -b hotfix/external-status-collision-fix
+
+# Implement fix
+# ... code changes ...
+
+# Test fix thoroughly
+bundle exec rspec spec/services/ci/create_commit_status_service_spec.rb
+bundle exec rspec spec/requests/api/commit_statuses_spec.rb
+
+# Deploy to staging
+# ... deployment process ...
+
+# Verify fix in staging
+# ... testing process ...
+```
+
+**Re-deployment Process:**
+1. Deploy fix to staging environment
+2. Run comprehensive test suite
+3. Perform manual testing of critical scenarios
+4. Get approval from incident commander
+5. Deploy to production with feature flag disabled
+6. Gradually re-enable feature flag
+7. Monitor closely for 24 hours
+
+#### Step 4: Post-Incident Review (1 week after resolution)
+
+**Review Process:**
+1. Conduct blameless post-mortem
+2. Document lessons learned
+3. Update rollback procedures based on experience
+4. Improve monitoring and alerting
+5. Update success criteria if needed
+
+**Process Improvements:**
+- Enhanced testing procedures
+- Better monitoring coverage
+- Improved rollback automation
+- Updated documentation
+- Team training updates
+
+### Rollback Testing
+
+#### Pre-deployment Rollback Testing
+
+**Staging Environment:**
+1. Deploy fix to staging
+2. Enable feature flag
+3. Simulate rollback scenario
+4. Verify system returns to baseline
+5. Test rollback automation
+
+**Production Readiness:**
+- Rollback scripts tested and verified
+- Monitoring alerts configured
+- Team trained on procedures
+- Communication templates prepared
+- Escalation paths defined
+
+#### Rollback Validation Checklist
+
+**Immediate Validation (0-30 minutes):**
+- [ ] Feature flag successfully disabled
+- [ ] API error rates return to baseline
+- [ ] Commit status creation works normally
+- [ ] Critical integrations functional
+- [ ] No data corruption detected
+
+**Extended Validation (30 minutes - 2 hours):**
+- [ ] Performance metrics return to normal
+- [ ] All monitoring alerts cleared
+- [ ] Integration partners notified
+- [ ] Support team briefed
+- [ ] Incident documentation started
+
+**Long-term Validation (2-24 hours):**
+- [ ] System stability maintained
+- [ ] No delayed side effects
+- [ ] User feedback collected
+- [ ] Root cause identified
+- [ ] Fix plan developed
+
+### Communication During Rollback
+
+#### Internal Communication
+
+**Immediate (0-15 minutes):**
+- Incident response team via Slack/PagerDuty
+- Engineering team leads
+- Support team managers
+- Product managers
+
+**Extended (15 minutes - 2 hours):**
+- All engineering teams
+- Customer support teams
+- Sales engineering (for enterprise customers)
+- Documentation teams
+
+#### External Communication
+
+**Customer-Facing:**
+- Status page update (if customer impact)
+- Support ticket template for affected users
+- Integration partner notification
+- Community forum post (if needed)
+
+**Integration Partners:**
+- Direct notification to Buildkite team
+- Jenkins plugin maintainers
+- Major enterprise customers using external CI
+
+### Recovery Procedures
+
+#### Data Recovery
+
+**If Data Corruption Occurs:**
+1. Immediately stop all write operations
+2. Assess scope of corruption
+3. Restore from most recent clean backup
+4. Replay transactions if possible
+5. Validate data integrity
+
+**Backup Strategy:**
+- Automated database backups every 4 hours
+- Point-in-time recovery capability
+- Separate backups for critical tables
+- Tested restore procedures
+
+#### Service Recovery
+
+**Performance Recovery:**
+1. Identify performance bottlenecks
+2. Scale resources if needed
+3. Optimize database queries
+4. Clear caches if corrupted
+5. Restart services if necessary
+
+**Integration Recovery:**
+1. Test all major integrations
+2. Provide updated API documentation
+3. Assist partners with migration issues
+4. Monitor integration health closely
+5. Provide dedicated support channel
+
+## Continuous Improvement
+
+### Success Criteria Evolution
+
+**Regular Review Schedule:**
+- Weekly during initial rollout
+- Monthly during stabilization period
+- Quarterly for long-term monitoring
+- Annual comprehensive review
+
+**Criteria Updates:**
+- Adjust thresholds based on actual performance
+- Add new metrics as system evolves
+- Remove obsolete criteria
+- Incorporate user feedback
+
+### Rollback Procedure Improvements
+
+**Automation Enhancements:**
+- Automated rollback triggers
+- Self-healing system capabilities
+- Improved monitoring and alerting
+- Faster deployment and rollback tools
+
+**Process Refinements:**
+- Streamlined communication procedures
+- Better escalation paths
+- Enhanced testing procedures
+- Improved documentation
+
+## Conclusion
+
+These success criteria and rollback procedures ensure that the external commit status collision fix
+can be deployed safely and effectively. The comprehensive monitoring and rollback capabilities
+provide confidence that any issues can be quickly identified and resolved, maintaining system
+stability while delivering the improved functionality users need.
+
+Regular review and improvement of these procedures will ensure they remain effective as the
+system evolves and new challenges emerge.
\ No newline at end of file
diff --git a/lib/api/commit_statuses.rb b/lib/api/commit_statuses.rb
index 34a5f502cec47260cb2b0d01b0f10ff317f59f3e..253d59808b946b3646a974cd0f609844b7bab68e 100644
--- a/lib/api/commit_statuses.rb
+++ b/lib/api/commit_statuses.rb
@@ -69,6 +69,36 @@ class CommitStatuses < ::API::Base
       # rubocop: enable CodeReuse/ActiveRecord
 
       desc 'Post status to a commit' do
+        detail <<~DESC
+          Creates a new commit status for the specified commit SHA.
+          
+          **Data Collection Notice (Phase 1):**
+          This API now includes instrumentation to detect and log cases where multiple users
+          post status updates for the same commit/ref/name combination. This data collection
+          helps understand usage patterns and the scope of potential duplicate external job issues.
+          
+          **Metrics Collected:**
+          - `external_commit_status_user_collisions_total`: Counter tracking collision events
+          - Structured logs with collision details for analysis
+          
+          **What constitutes a collision:**
+          A collision is detected when a different user attempts to create a status for the same:
+          - Project
+          - Commit SHA  
+          - Git reference (branch/tag)
+          - Status name
+          - Pipeline (if existing running/pending status exists)
+          
+          **Privacy:**
+          Logged data includes project ID, user IDs, commit SHA, ref, and status name.
+          No sensitive content from status descriptions or target URLs is logged.
+          
+          **Impact:**
+          This instrumentation does not change API behavior - all status creation requests
+          continue to work exactly as before. The data collection is purely observational
+          to inform future improvements to external job handling.
+        DESC
+        
         success code: 200, model: Entities::CommitStatus
         failure [
           { code: 400, message: 'Bad request' },
diff --git a/spec/services/ci/create_commit_status_service_spec.rb b/spec/services/ci/create_commit_status_service_spec.rb
index 2f21be6a20325653f1514b301d52d768baa65a62..ebbd25f439eb2a826d28ecc68d2c31445302c94c 100644
--- a/spec/services/ci/create_commit_status_service_spec.rb
+++ b/spec/services/ci/create_commit_status_service_spec.rb
@@ -647,4 +647,374 @@ def execute_service(params = self.params)
       .new(project, user, params)
       .execute(optional_commit_status_params: params.slice(*%i[target_url description coverage]))
   end
+
+  describe 'external commit status user collision detection' do
+    let(:params) { { state: 'pending', name: 'test-job', ref: 'master' } }
+    let(:other_user) { create_user(:developer) }
+    let(:collision_counter) { instance_double(Prometheus::Client::Counter) }
+
+    before do
+      allow(Gitlab::Metrics).to receive(:counter)
+        .with(:external_commit_status_user_collisions_total, 'Total number of external commit status user collisions detected')
+        .and_return(collision_counter)
+      allow(collision_counter).to receive(:increment)
+    end
+
+    context 'when no existing status from different user exists' do
+      it 'does not log collision or increment counter' do
+        expect(Gitlab::AppJsonLogger).not_to receive(:info).with(hash_including(event: 'external_commit_status_user_collision'))
+        expect(collision_counter).not_to receive(:increment)
+
+        response = execute_service(params)
+        expect(response).to be_success
+      end
+    end
+
+    context 'when existing status from same user exists' do
+      before do
+        execute_service(params)
+      end
+
+      it 'does not log collision or increment counter' do
+        expect(Gitlab::AppJsonLogger).not_to receive(:info).with(hash_including(event: 'external_commit_status_user_collision'))
+        expect(collision_counter).not_to receive(:increment)
+
+        response = execute_service(params)
+        expect(response).to be_success
+      end
+    end
+
+    context 'when existing status from different user exists' do
+      let!(:existing_pipeline) { create(:ci_pipeline, project: project, sha: commit.id, ref: 'master') }
+      let!(:existing_status) do
+        create(:generic_commit_status,
+               pipeline: existing_pipeline,
+               name: 'test-job',
+               ref: 'master',
+               user: other_user,
+               status: 'pending')
+      end
+
+      it 'logs collision details and increments counter' do
+        expect(Gitlab::AppJsonLogger).to receive(:info).with(
+          class: 'Ci::CreateCommitStatusService',
+          event: 'external_commit_status_user_collision',
+          project_id: project.id,
+          pipeline_id: kind_of(Integer),
+          commit_sha: commit.id,
+          ref: 'master',
+          status_name: 'test-job',
+          current_user_id: user.id,
+          existing_user_ids: [other_user.id],
+          existing_status_count: 1,
+          subscription_plan: project.actual_plan_name
+        )
+
+        expect(collision_counter).to receive(:increment).with(
+          project_path: project.full_path,
+          ref_protected: 'false'
+        )
+
+        response = execute_service(params)
+        expect(response).to be_success
+      end
+
+      context 'with protected ref' do
+        before do
+          create(:protected_branch, project: project, name: 'master')
+        end
+
+        it 'logs collision with protected ref status' do
+          expect(collision_counter).to receive(:increment).with(
+            project_path: project.full_path,
+            ref_protected: 'true'
+          )
+
+          execute_service(params.merge(user: create_user(:maintainer)))
+        end
+      end
+
+      context 'with multiple existing statuses from different users' do
+        let(:third_user) { create_user(:developer) }
+        let!(:another_existing_status) do
+          create(:generic_commit_status,
+                 pipeline: existing_pipeline,
+                 name: 'test-job',
+                 ref: 'master',
+                 user: third_user,
+                 status: 'pending')
+        end
+
+        it 'logs all existing user IDs and correct count' do
+          expect(Gitlab::AppJsonLogger).to receive(:info).with(
+            hash_including(
+              existing_user_ids: match_array([other_user.id, third_user.id]),
+              existing_status_count: 2
+            )
+          )
+
+          response = execute_service(params)
+          expect(response).to be_success
+        end
+      end
+
+      context 'when existing status is not running or pending' do
+        before do
+          existing_status.update!(status: 'success')
+        end
+
+        it 'does not log collision or increment counter' do
+          expect(Gitlab::AppJsonLogger).not_to receive(:info).with(hash_including(event: 'external_commit_status_user_collision'))
+          expect(collision_counter).not_to receive(:increment)
+
+          response = execute_service(params)
+          expect(response).to be_success
+        end
+      end
+
+      context 'when existing status has different name' do
+        before do
+          existing_status.update!(name: 'different-job')
+        end
+
+        it 'does not log collision or increment counter' do
+          expect(Gitlab::AppJsonLogger).not_to receive(:info).with(hash_including(event: 'external_commit_status_user_collision'))
+          expect(collision_counter).not_to receive(:increment)
+
+          response = execute_service(params)
+          expect(response).to be_success
+        end
+      end
+
+      context 'when existing status has different ref' do
+        before do
+          existing_status.update!(ref: 'develop')
+        end
+
+        it 'does not log collision or increment counter' do
+          expect(Gitlab::AppJsonLogger).not_to receive(:info).with(hash_including(event: 'external_commit_status_user_collision'))
+          expect(collision_counter).not_to receive(:increment)
+
+          response = execute_service(params)
+          expect(response).to be_success
+        end
+      end
+    end
+
+    context 'buildkite-style integration scenario' do
+      let(:buildkite_user_1) { create_user(:developer) }
+      let(:buildkite_user_2) { create_user(:developer) }
+      let(:buildkite_params) do
+        {
+          state: 'pending',
+          name: 'buildkite-test',
+          ref: 'main',
+          description: 'Buildkite test job',
+          target_url: 'https://buildkite.com/example/build/123'
+        }
+      end
+
+      it 'detects collision when second user posts same job status' do
+        # First user posts status
+        first_response = described_class
+          .new(project, buildkite_user_1, buildkite_params)
+          .execute(optional_commit_status_params: buildkite_params.slice(*%i[target_url description coverage]))
+        expect(first_response).to be_success
+
+        # Second user posts same status - should detect collision
+        expect(Gitlab::AppJsonLogger).to receive(:info).with(
+          hash_including(
+            event: 'external_commit_status_user_collision',
+            current_user_id: buildkite_user_2.id,
+            existing_user_ids: [buildkite_user_1.id],
+            status_name: 'buildkite-test'
+          )
+        )
+
+        expect(collision_counter).to receive(:increment)
+
+        second_response = described_class
+          .new(project, buildkite_user_2, buildkite_params)
+          .execute(optional_commit_status_params: buildkite_params.slice(*%i[target_url description coverage]))
+        expect(second_response).to be_success
+
+        # Verify both statuses exist (current behavior)
+        statuses = project.commit_statuses.where(name: 'buildkite-test')
+        expect(statuses.count).to eq(2)
+        expect(statuses.map(&:user_id)).to match_array([buildkite_user_1.id, buildkite_user_2.id])
+      end
+    end
+
+    context 'integration test: multiple buildkite agents posting statuses' do
+      let(:buildkite_agent_1) { create_user(:developer) }
+      let(:buildkite_agent_2) { create_user(:developer) }
+      let(:buildkite_agent_3) { create_user(:developer) }
+      
+      let(:test_commit_sha) { project.repository.commit.id }
+      let(:test_ref) { 'feature-branch' }
+      
+      let(:job_configs) do
+        [
+          { name: 'unit-tests', description: 'Running unit tests' },
+          { name: 'integration-tests', description: 'Running integration tests' },
+          { name: 'lint', description: 'Running linter' }
+        ]
+      end
+
+      it 'correctly instruments collision patterns across multiple jobs and users' do
+        collision_events = []
+        allow(Gitlab::AppJsonLogger).to receive(:info) do |log_data|
+          collision_events << log_data if log_data[:event] == 'external_commit_status_user_collision'
+        end
+
+        counter_increments = 0
+        allow(collision_counter).to receive(:increment) { counter_increments += 1 }
+
+        # Simulate Buildkite posting initial pending statuses from agent 1
+        job_configs.each do |job_config|
+          params = {
+            sha: test_commit_sha,
+            state: 'pending',
+            name: job_config[:name],
+            ref: test_ref,
+            description: job_config[:description],
+            target_url: "https://buildkite.com/example/#{job_config[:name]}/123"
+          }
+
+          response = described_class
+            .new(project, buildkite_agent_1, params)
+            .execute(optional_commit_status_params: params.slice(*%i[target_url description coverage]))
+          expect(response).to be_success
+        end
+
+        # No collisions yet
+        expect(collision_events).to be_empty
+        expect(counter_increments).to eq(0)
+
+        # Simulate agent 2 posting updates for same jobs (collision scenario)
+        job_configs.each do |job_config|
+          params = {
+            sha: test_commit_sha,
+            state: 'running',
+            name: job_config[:name],
+            ref: test_ref,
+            description: "#{job_config[:description]} - Updated by agent 2",
+            target_url: "https://buildkite.com/example/#{job_config[:name]}/123"
+          }
+
+          response = described_class
+            .new(project, buildkite_agent_2, params)
+            .execute(optional_commit_status_params: params.slice(*%i[target_url description coverage]))
+          expect(response).to be_success
+        end
+
+        # Should detect 3 collisions (one per job)
+        expect(collision_events.size).to eq(3)
+        expect(counter_increments).to eq(3)
+
+        # Verify collision details
+        collision_events.each do |event|
+          expect(event).to include(
+            class: 'Ci::CreateCommitStatusService',
+            event: 'external_commit_status_user_collision',
+            project_id: project.id,
+            commit_sha: test_commit_sha,
+            ref: test_ref,
+            current_user_id: buildkite_agent_2.id,
+            existing_user_ids: [buildkite_agent_1.id],
+            existing_status_count: 1,
+            subscription_plan: project.actual_plan_name
+          )
+        end
+
+        # Simulate agent 3 posting to one job (additional collision)
+        params = {
+          sha: test_commit_sha,
+          state: 'success',
+          name: 'unit-tests',
+          ref: test_ref,
+          description: 'Unit tests completed successfully',
+          target_url: 'https://buildkite.com/example/unit-tests/123'
+        }
+
+        response = described_class
+          .new(project, buildkite_agent_3, params)
+          .execute(optional_commit_status_params: params.slice(*%i[target_url description coverage]))
+        expect(response).to be_success
+
+        # Should detect one more collision with 2 existing users
+        expect(collision_events.size).to eq(4)
+        expect(counter_increments).to eq(4)
+
+        last_collision = collision_events.last
+        expect(last_collision[:existing_user_ids]).to match_array([buildkite_agent_1.id, buildkite_agent_2.id])
+        expect(last_collision[:existing_status_count]).to eq(2)
+
+        # Verify final state: 3 jobs × 3 users = 9 total statuses created
+        total_statuses = project.commit_statuses.where(sha: test_commit_sha, ref: test_ref)
+        expect(total_statuses.count).to eq(7) # 3 + 3 + 1 (agent 3 only posted to one job)
+
+        # Verify each job has multiple statuses from different users
+        job_configs.each do |job_config|
+          job_statuses = total_statuses.where(name: job_config[:name])
+          if job_config[:name] == 'unit-tests'
+            expect(job_statuses.count).to eq(3) # All 3 agents posted
+            expect(job_statuses.map(&:user_id)).to match_array([buildkite_agent_1.id, buildkite_agent_2.id, buildkite_agent_3.id])
+          else
+            expect(job_statuses.count).to eq(2) # Only agents 1 and 2 posted
+            expect(job_statuses.map(&:user_id)).to match_array([buildkite_agent_1.id, buildkite_agent_2.id])
+          end
+        end
+      end
+
+      it 'handles rapid concurrent status posting from multiple users' do
+        collision_events = []
+        allow(Gitlab::AppJsonLogger).to receive(:info) do |log_data|
+          collision_events << log_data if log_data[:event] == 'external_commit_status_user_collision'
+        end
+
+        counter_increments = 0
+        allow(collision_counter).to receive(:increment) { counter_increments += 1 }
+
+        # Simulate concurrent posting (race condition scenario)
+        threads = []
+        users = [buildkite_agent_1, buildkite_agent_2, buildkite_agent_3]
+        
+        users.each do |user|
+          threads << Thread.new do
+            params = {
+              sha: test_commit_sha,
+              state: 'pending',
+              name: 'concurrent-test',
+              ref: test_ref,
+              description: "Posted by #{user.username}",
+              target_url: 'https://buildkite.com/example/concurrent-test/123'
+            }
+
+            response = Gitlab::ExclusiveLease.skipping_transaction_check do
+              described_class
+                .new(project, user, params)
+                .execute(optional_commit_status_params: params.slice(*%i[target_url description coverage]))
+            end
+            expect(response).to be_success
+          end
+        end
+
+        threads.each(&:join)
+
+        # Should detect some collisions (exact number depends on timing)
+        expect(counter_increments).to be >= 0
+        expect(counter_increments).to be <= 2 # Maximum possible collisions
+
+        # Verify all statuses were created
+        concurrent_statuses = project.commit_statuses.where(
+          sha: test_commit_sha,
+          ref: test_ref,
+          name: 'concurrent-test'
+        )
+        expect(concurrent_statuses.count).to eq(3)
+        expect(concurrent_statuses.map(&:user_id)).to match_array(users.map(&:id))
+      end
+    end
+  end
 end