Integrations

ServiceNow GitHub Integration Guide

intermediatePersonal Access Token (Bearer token authentication)GitHub

The ServiceNow GitHub integration enables automated DevOps workflows by connecting ServiceNow's change management and incident processes with GitHub's source control and issue tracking capabilities. This integration solves critical business problems around deployment automation, incident-to-defect traceability, and maintaining audit trails between operational changes and code releases. Development teams, DevOps engineers, and ServiceNow administrators use this integration to streamline their software delivery pipeline. The integration supports bidirectional data flows including triggering GitHub Actions deployments from approved ServiceNow change requests, automatically creating GitHub issues from ServiceNow incidents, and receiving webhook notifications from GitHub to update ServiceNow records. The primary automation patterns leverage IntegrationHub flows and GitHub webhooks, with configuration managed through the IntegrationHub application in ServiceNow.

Prerequisites

  • ServiceNow Paris release or later with IntegrationHub Starter license minimum
  • GitHub organization or personal account with repository admin access
  • GitHub Personal Access Token with repo, issues, and actions scopes
  • ServiceNow admin role or itil role with Flow Designer access
  • IntegrationHub GitHub spoke installed from ServiceNow Store
  • Outbound HTTP requests enabled in ServiceNow instance
  • Valid SSL certificates configured for webhook endpoints

Architecture Overview

The integration uses the official ServiceNow IntegrationHub GitHub spoke which provides pre-built actions for repository operations, issue management, and webhook handling. Authentication is established using GitHub Personal Access Tokens stored in ServiceNow Connection & Credential Alias records, with the spoke handling OAuth token refresh automatically. Data flows bidirectionally with ServiceNow initiating outbound REST calls to GitHub's API and GitHub sending webhook payloads to ServiceNow's Scripted REST API endpoints. No MID Server is required since GitHub's public APIs are accessible over HTTPS, but webhook endpoints must be configured with proper authentication tokens. GitHub enforces rate limiting of 5000 requests per hour for authenticated users, and webhook deliveries have a 10-second timeout, which should be considered when designing high-volume integrations.

Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Implementation Steps

1

Install and configure the GitHub spoke from ServiceNow Store

Navigate to System Applications > All Available Applications > All and search for 'GitHub Spoke'. Click Install on the official ServiceNow GitHub spoke application and wait for installation to complete. After installation, navigate to IntegrationHub > Connections & Credentials > Connection & Credential Aliases to verify the GitHub connection template is available. The spoke includes pre-built actions for creating repositories, managing issues, triggering workflows, and handling pull requests. Verify the spoke is active by checking System Applications > My Company Applications and confirming GitHub Spoke shows as Active.

2

Create GitHub Personal Access Token with required permissions

Log into GitHub and navigate to Settings > Developer Settings > Personal Access Tokens > Tokens (classic). Click Generate new token and provide a descriptive name like 'ServiceNow Integration Token'. Select the following scopes: repo (full repository access), issues (read/write issues), actions (read/write GitHub Actions), and admin:repo_hook (webhook management). Set an appropriate expiration date and copy the generated token immediately as it won't be displayed again. Store this token securely as it will be used to authenticate all ServiceNow requests to GitHub.

3

Configure Connection and Credential Alias in ServiceNow

Navigate to IntegrationHub > Connections & Credentials > Connection & Credential Aliases and click New. Set the Name to 'GitHub Production Connection' and Type to 'GitHub'. In the Connection section, set the Base URL to 'https://api.github.com' and Connection timeout to 30 seconds. In the Credential section, select 'Use existing credential' and click the search icon to create a new Basic Auth credential. Set the User name to your GitHub username and Password to the Personal Access Token created in the previous step, then save the credential and connection alias.

4

Create a test Flow to verify GitHub connectivity

Navigate to Process Automation > Flow Designer and click New > Flow. Name the flow 'Test GitHub Connection' and set it to run as 'System User'. Add a GitHub spoke action by clicking the + button and searching for 'GitHub'. Select the 'Get Repository' action and configure it with your Connection Alias from step 3. Set the Owner field to your GitHub username or organization and Repository to an existing repository name. Add a Log action after the GitHub action to output the response. Save and test the flow to verify successful connection - you should see repository details in the execution log.

ServiceNow Script
// Flow Designer GitHub Action Configuration
// Action: Get Repository
// Connection: GitHub Production Connection
// Owner: your-github-username
// Repository: your-repo-name
// The action will return repository metadata including full_name, description, and default_branch
5

Configure webhook endpoint for GitHub events in ServiceNow

Navigate to System Web Services > Scripted REST APIs and click New. Set the Name to 'GitHub Webhook Handler', API ID to 'github_webhook', and make it Active. Create a new resource with HTTP method POST, Relative path '/payload', and set Security to 'Inherit from parent'. In the resource script, implement webhook signature verification using HMAC-SHA256 and the webhook secret. The script should parse the GitHub payload and create or update appropriate ServiceNow records based on the event type. Configure error handling to return appropriate HTTP status codes to GitHub's webhook delivery system.

ServiceNow Script
(function process(request, response) {
    var payload = request.body.dataString;
    var signature = request.getHeader('X-Hub-Signature-256');
    var eventType = request.getHeader('X-GitHub-Event');
    
    // Verify webhook signature
    var secretKey = gs.getProperty('github.webhook.secret');
    var expectedSig = 'sha256=' + GlideDigest.getMD5Base64(secretKey + payload);
    
    if (signature !== expectedSig) {
        response.setStatus(401);
        response.setBody('Unauthorized');
        return;
    }
    
    var data = JSON.parse(payload);
    gs.info('GitHub webhook received: ' + eventType + ' for repo: ' + data.repository.full_name);
    
    response.setStatus(200);
    response.setBody('OK');
})(request, response);
6

Set up webhook in GitHub repository pointing to ServiceNow

In your GitHub repository, navigate to Settings > Webhooks and click Add webhook. Set the Payload URL to your ServiceNow instance URL followed by '/api/sn_integration_github_webhook/github_webhook/payload' (example: https://dev12345.service-now.com/api/github_webhook/payload). Select 'application/json' as the Content type and generate a random secret string for webhook security. Choose 'Let me select individual events' and select events like push, pull request, issues, and workflow run. Ensure the webhook is Active and click Add webhook. GitHub will send a ping event to test connectivity - verify this appears in your ServiceNow system logs.

7

Create Flow to trigger GitHub Actions from Change Requests

Navigate to Flow Designer and create a new flow named 'Trigger Deployment from Change'. Set the trigger to 'Record Updated' on the Change Request table with condition 'State is Implement'. Add a GitHub spoke action 'Create Repository Dispatch Event' and configure it with your connection alias. Set the Repository Owner, Repository name, and Event Type (like 'deploy-prod'). Map Change Request fields to the client payload including change number, short description, and deployment window. Add error handling to update the change request work notes if the GitHub action fails. Test the flow by updating a change request to Implement state and verifying the GitHub Action is triggered.

ServiceNow Script
// Flow Data Mapping for Repository Dispatch
// Event Type: 'servicenow-deployment'
// Client Payload:
{
    "change_number": "{{trigger.current.number}}",
    "change_description": "{{trigger.current.short_description}}",
    "deployment_window": "{{trigger.current.start_date}}",
    "environment": "production",
    "requested_by": "{{trigger.current.requested_by.display_value}}"
}
8

Implement incident to GitHub issue creation workflow

Create a new Flow triggered by 'Record Created' on the Incident table with conditions for high priority incidents (Priority 1 or 2). Add a GitHub spoke action 'Create Issue' and map incident fields to GitHub issue fields: map incident short description to issue title, description to issue body, and add labels based on incident category. Include ServiceNow incident URL in the issue body for bi-directional traceability. Store the created GitHub issue number in a custom field on the ServiceNow incident record for future reference. Add a final action to update incident work notes confirming the GitHub issue was created successfully.

ServiceNow Script
// GitHub Issue Creation Data Mapping
// Title: "{{trigger.current.short_description}}"
// Body: "Incident Number: {{trigger.current.number}}\n\nDescription: {{trigger.current.description}}\n\nServiceNow URL: https://instance.service-now.com/nav_to.do?uri=incident.do?sys_id={{trigger.current.sys_id}}"
// Labels: ["servicenow-incident", "{{trigger.current.category}}"]

Common Use Cases

Automated deployment triggers from approved change requests

When a change request moves to 'Implement' state, ServiceNow automatically triggers a GitHub Actions workflow using repository dispatch events. The workflow receives change metadata including deployment window, change number, and approval details to execute environment-specific deployments. This use case ensures deployments only occur for properly approved changes and maintains audit trails between ITSM processes and code deployments. The integration reduces manual handoffs between change management and deployment teams while enforcing governance controls.

GitHub issue creation from high-priority ServiceNow incidents

Critical incidents (Priority 1-2) automatically create corresponding GitHub issues in relevant development repositories, ensuring development teams are immediately aware of production issues. The GitHub issue includes incident details, ServiceNow URL for context, and appropriate labels for triage and assignment. This use case accelerates incident resolution by bringing development visibility into operational issues and creating a direct link between incidents and potential code fixes. Work notes are synchronized bidirectionally to maintain communication history in both systems.

Pull request approval workflow integration with change management

GitHub webhooks notify ServiceNow when pull requests are opened, triggering automatic change request creation for production deployments. The change request includes pull request details, code diff summaries, and reviewer information to support change advisory board reviews. This integration ensures all production code changes follow proper change management processes while reducing duplicate data entry. Change approval or rejection updates the pull request status and notifies developers through GitHub's notification system.

Failed GitHub Actions workflow incident creation

GitHub webhooks detect failed workflow runs and automatically create ServiceNow incidents with appropriate priority based on the affected environment and failure type. The incident includes workflow logs, failure reason, commit information, and affected services for rapid triage and resolution. This proactive monitoring approach ensures deployment failures are immediately escalated through proper incident management channels. The integration supports different incident priorities and assignment groups based on repository, branch, and workflow type.

Release documentation synchronization between platforms

ServiceNow change requests scheduled for deployment automatically update GitHub release documentation with implementation details, rollback procedures, and post-deployment verification steps. Conversely, GitHub releases trigger ServiceNow knowledge article creation containing release notes, known issues, and support procedures. This bidirectional synchronization ensures consistent documentation across development and operations teams while reducing manual documentation overhead. Version tags and release artifacts are cross-referenced between both platforms for complete traceability.

Troubleshooting

401 Unauthorized error when GitHub spoke actions execute

Verify the Personal Access Token in your Connection & Credential Alias is still valid and has the required scopes. Navigate to IntegrationHub > Connections & Credentials and test the connection by clicking the Test button. Check the token expiration date in GitHub Settings and regenerate if necessary. Ensure the token has repo, issues, and actions scopes enabled, and verify the GitHub username matches the token owner in the credential configuration.

Webhook payloads received but no ServiceNow records created

Check the Scripted REST API logs by navigating to System Logs > All and filtering for 'github_webhook' source. Verify the webhook signature validation is working correctly and the shared secret matches between GitHub and ServiceNow. Examine the webhook delivery details in GitHub repository settings to confirm successful HTTP 200 responses. Add debug logging to your webhook handler script to trace payload processing and identify where record creation is failing.

GitHub Actions workflow dispatch events not triggering workflows

Confirm the GitHub repository has a workflow file (.github/workflows/*.yml) configured to listen for repository_dispatch events with the correct event type. Verify the workflow file syntax is valid and the event type in your ServiceNow flow matches exactly (case-sensitive). Check GitHub Actions logs to see if the event was received and ensure the workflow has proper permissions to access repository contents. Test the repository dispatch manually using GitHub's REST API to isolate ServiceNow integration issues.

Flow execution fails with timeout errors on GitHub API calls

Increase the connection timeout value in your Connection & Credential Alias from the default 30 seconds to 60 seconds for large repository operations. Check GitHub's status page for API performance issues and implement retry logic in your flows using the 'Wait' action with exponential backoff. Monitor your GitHub API rate limit usage by adding a 'Get Rate Limit' action to your flows and implement conditional logic to pause when approaching limits. Consider implementing asynchronous processing for bulk operations using GitHub's webhook callbacks.

ServiceNow webhook endpoint returns 500 errors causing GitHub webhook failures

Enable detailed error logging in your Scripted REST API by wrapping the main logic in try-catch blocks and logging exceptions with gs.error(). Check for common issues like invalid JSON parsing, missing system properties, or database transaction conflicts in high-volume scenarios. Verify your webhook handler has proper ACL permissions and the executing user has rights to create or update target records. Test webhook payloads using ServiceNow's REST API Explorer to reproduce errors outside of GitHub's webhook system.

Duplicate records created when GitHub sends webhook retry attempts

Implement idempotency checking in your webhook handler using GitHub's delivery UUID from the X-GitHub-Delivery header to prevent duplicate processing. Store processed delivery IDs in a custom table with timestamps for cleanup and deduplication logic. Add database constraints or business rules to prevent duplicate records based on GitHub event IDs, commit SHAs, or issue numbers. Configure appropriate HTTP status code responses (200 for success, 400 for bad requests) to prevent unnecessary GitHub webhook retries.

Pro Tips

  • Implement webhook signature verification using HMAC-SHA256 with a rotating secret stored in encrypted system properties to prevent unauthorized webhook payloads from creating ServiceNow records. Use GlideDigest.getHMAC() method for secure signature validation and always validate the timestamp header to prevent replay attacks.
  • Create custom GitHub connection health monitoring by building a scheduled job that tests API connectivity and token validity, automatically creating incidents when authentication failures occur. This proactive approach prevents integration failures during critical deployment windows and provides early warning for token expiration.
  • Use GitHub's GraphQL API instead of REST API for complex queries requiring multiple repository or organization details to reduce API call volume and improve performance. The IntegrationHub spoke supports custom HTTP requests, allowing you to implement GraphQL queries while staying within rate limits.
  • Implement circuit breaker patterns in high-volume webhook processing by using ServiceNow's job queue system to handle webhook payloads asynchronously during GitHub outages or high-traffic periods. This prevents webhook timeout failures and ensures reliable event processing during peak usage.
  • Create GitHub repository templates with standardized workflow files that include ServiceNow integration points, making it easier for development teams to adopt the integration patterns across multiple projects. Include examples of repository dispatch handling, workflow status reporting, and deployment approval gates.
  • Use ServiceNow's Transform Maps for complex GitHub webhook payload processing, especially when dealing with different event types that require different record creation logic. This approach provides better maintainability and allows for field mapping changes without code modifications.

Known Limitations

  • GitHub's API rate limiting restricts authenticated users to 5000 requests per hour, which can be exceeded in high-volume environments with frequent webhook events or batch processing. Consider implementing request queuing and throttling mechanisms for organizations with multiple repositories and active development teams.
  • The IntegrationHub GitHub spoke requires an active IntegrationHub Starter license minimum, with some advanced features requiring Professional licenses for complex workflow orchestration. Personal Developer Instances (PDI) may have limited spoke functionality and webhook processing capabilities that don't reflect production behavior.
  • GitHub webhooks have a 10-second timeout for HTTP responses, requiring ServiceNow webhook handlers to process payloads quickly or implement asynchronous processing patterns. Complex record creation or external API calls within webhook handlers may cause timeout failures and webhook delivery retries.
  • Large GitHub repositories with extensive commit histories or file trees may cause API response payloads that exceed ServiceNow's default HTTP response size limits. This is particularly problematic when fetching repository contents, commit diffs, or comprehensive issue data requiring pagination handling.
  • GitHub's webhook delivery retry mechanism uses exponential backoff over several hours, but ServiceNow maintenance windows or instance hibernation can cause permanent webhook delivery failures. There's no built-in mechanism to replay missed webhooks, requiring custom solutions for critical event recovery.

Frequently Asked Questions

Can I use GitHub Enterprise Server (on-premises) with the ServiceNow GitHub spoke?

Yes, the GitHub spoke supports GitHub Enterprise Server by modifying the base URL in the Connection & Credential Alias to point to your on-premises GitHub instance API endpoint (typically https://github.company.com/api/v3). You'll need to ensure network connectivity between ServiceNow and your GitHub Enterprise Server, potentially requiring MID Server configuration if the GitHub instance is behind a firewall. The spoke actions and webhook functionality work identically to GitHub.com with proper authentication configuration.

How do I handle GitHub organization repositories with different access permissions?

Create separate Connection & Credential Alias records for different GitHub organizations or access levels, using organization-specific Personal Access Tokens with appropriate permissions. In your Flow Designer workflows, use conditional logic to select the correct connection based on repository owner or project requirements. Consider using GitHub Apps instead of Personal Access Tokens for organization-wide integrations, as they provide more granular permissions and better security audit trails. The ServiceNow GitHub spoke supports multiple connection aliases within the same instance for this scenario.

What happens if my GitHub Personal Access Token expires during production workflows?

GitHub Personal Access Token expiration will cause all ServiceNow GitHub spoke actions to fail with 401 authentication errors, potentially disrupting deployment workflows and incident creation processes. Implement proactive monitoring by creating scheduled flows that test GitHub connectivity and alert administrators before token expiration. Consider using GitHub Apps with automatic token refresh capabilities for production environments, or establish token rotation procedures with calendar reminders well before expiration dates. The Connection & Credential Alias test functionality can be used in scheduled health checks to detect authentication failures.

Can I customize the GitHub webhook payload processing beyond the standard spoke actions?

Absolutely, you can create custom Scripted REST API endpoints to handle GitHub webhooks with completely customized logic beyond the spoke's standard actions. This approach allows for complex payload parsing, conditional record creation, and integration with other ServiceNow modules like Asset Management or Security Operations. Use the spoke actions within custom flows triggered by your webhook handler for the best of both worlds - custom processing logic with pre-built GitHub API interactions. Remember to implement proper error handling and response codes to maintain reliable webhook delivery from GitHub.

How do I implement bidirectional synchronization between ServiceNow incidents and GitHub issues?

Implement bidirectional sync using a combination of ServiceNow business rules and GitHub webhooks with careful conflict resolution logic. Create unique identifier fields in both systems to track relationships, and use 'last modified' timestamps to determine sync direction during conflicts. Set up GitHub webhooks for issue events (opened, closed, commented) that update corresponding ServiceNow incidents, while ServiceNow business rules on incident updates push changes back to GitHub issues. Consider implementing sync status tracking to handle temporary failures and prevent infinite sync loops between the platforms.

What's the best practice for handling GitHub webhook retries and duplicate events?

Implement idempotency using GitHub's X-GitHub-Delivery header as a unique identifier for each webhook delivery attempt, storing processed delivery IDs in a ServiceNow table to prevent duplicate processing. Use GitHub's X-GitHub-Event and action fields to implement event-specific deduplication logic, particularly for events like pull requests that may trigger multiple webhooks. Set up proper HTTP response codes (200 for success, 400 for bad requests, 500 for retryable errors) to control GitHub's retry behavior. Consider implementing a dead letter queue pattern for webhook payloads that fail processing multiple times.

Can I use the GitHub integration to manage ServiceNow application development and deployment?

Yes, you can integrate GitHub with ServiceNow's application development lifecycle by using GitHub repositories to store ServiceNow application source code exported via Update Sets or the ServiceNow CLI. Set up GitHub Actions workflows that automatically import Update Sets or deploy applications to target ServiceNow instances when code is merged to specific branches. Use the integration to trigger ServiceNow application deployment through change management processes, ensuring proper approval workflows for production deployments. This approach enables GitOps practices for ServiceNow development with full audit trails and rollback capabilities through version control.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue