Jenkins Notifications and Reporting
Notifications keep your team informed about build results without requiring anyone to watch the Jenkins dashboard. Reports give developers and managers the data they need to understand build health, test trends, and code quality over time.
A build failure is only useful if someone learns about it quickly. A notification system makes sure the right people hear about problems within seconds of them happening.
Email Notifications
Email is the most universal notification method. Jenkins has two email systems: the basic Email Notification and the more powerful Email Extension plugin.
Basic Email Notification (Post-Build Action)
In Freestyle job Post-Build Actions: Add: Email Notification Recipients: dev-team@company.com Check: Send email for every failed build Check: Send email to individuals who broke the build Jenkins sends a plain-text email when a build fails and again when it recovers.
Email Extension Plugin (Full Control)
The Email Extension plugin (emailext) gives you full control over when to send, who receives it, what the subject says, and what the body contains — including HTML templates with build logs attached.
post {
failure {
emailext(
to: 'dev-team@company.com',
subject: "FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: """
Build failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}
Branch: ${env.GIT_BRANCH}
Commit: ${env.GIT_COMMIT}
Build URL: ${env.BUILD_URL}
Duration: ${currentBuild.durationString}
""",
attachLog: true, // Attach console log as a file
compressLog: true // Compress the log before attaching
)
}
success {
emailext(
to: 'release-team@company.com',
subject: "SUCCESS: ${env.JOB_NAME} #${env.BUILD_NUMBER} deployed",
body: "Version ${env.BUILD_NUMBER} is live on production."
)
}
unstable {
emailext(
to: 'qa-team@company.com',
subject: "UNSTABLE: Tests failing in ${env.JOB_NAME}",
body: "Some tests are failing. Review the test report: ${env.BUILD_URL}testReport/"
)
}
}
Slack Notifications
Slack notifications deliver instant build updates to team channels. The Slack Notification plugin connects Jenkins to any Slack workspace.
Setup
Step 1: In Slack: Create a Slack App or use Incoming Webhooks Generate a webhook URL or bot token Add bot to the target channel Step 2: In Jenkins: Manage Jenkins → System → Slack Workspace: your-team.slack.com Credentials: Add the Slack token as Secret Text Default Channel: #builds Step 3: Install "Slack Notification" plugin
Slack in a Pipeline
post {
success {
slackSend(
channel: '#deployments',
color: 'good', // green
message: """
✅ *DEPLOYED*: ${env.JOB_NAME} #${env.BUILD_NUMBER}
Branch: ${env.GIT_BRANCH}
Duration: ${currentBuild.durationString}
<${env.BUILD_URL}|View Build>
"""
)
}
failure {
slackSend(
channel: '#alerts',
color: 'danger', // red
message: """
❌ *FAILED*: ${env.JOB_NAME} #${env.BUILD_NUMBER}
Branch: ${env.GIT_BRANCH}
<${env.BUILD_URL}console|View Console Output>
"""
)
}
unstable {
slackSend(
channel: '#builds',
color: 'warning', // yellow
message: "⚠️ UNSTABLE: ${env.JOB_NAME} #${env.BUILD_NUMBER} — tests failing"
)
}
}
Slack message example: #deployments channel: ┌─────────────────────────────────────────────┐ │ ✅ DEPLOYED: order-service #145 │ │ Branch: main │ │ Duration: 4 min 22 sec │ │ View Build │ └─────────────────────────────────────────────┘ #alerts channel: ┌─────────────────────────────────────────────┐ │ ❌ FAILED: payment-service #87 │ │ Branch: feature/refund-logic │ │ View Console Output │ └─────────────────────────────────────────────┘
Microsoft Teams Notifications
Teams notifications work through webhook connectors in the Office 365 Connector plugin or the MS Teams Notifier plugin.
post {
always {
office365ConnectorSend(
webhookUrl: 'https://outlook.office.com/webhook/...',
status: currentBuild.currentResult,
message: "Build ${env.JOB_NAME} #${env.BUILD_NUMBER}: ${currentBuild.currentResult}"
)
}
}
GitHub / GitLab Status Updates
Jenkins reports build status directly on pull requests in GitHub or GitLab. A green check or red cross appears next to the commit, giving reviewers instant visibility into whether the code passed CI.
Diagram: GitHub PR with Jenkins status Pull Request: Add payment validation ┌──────────────────────────────────────────────┐ │ Commits: 3 Files changed: 8 │ │ │ │ Checks: │ │ ✓ CI/Jenkins — All checks passed Details │ │ ✓ SonarQube — Quality gate passed Details │ │ │ │ [Merge pull request] ← Enabled │ └──────────────────────────────────────────────┘ OR if build fails: │ ✗ CI/Jenkins — Build failed Details │ │ [Merge pull request] ← BLOCKED │
Set GitHub commit status in pipeline:
// Using GitHub plugin's built-in reporting (automatic with Multibranch)
// Or manually:
githubNotify(
status: 'SUCCESS',
description: 'All checks passed',
context: 'CI/Jenkins'
)
Build History and Trend Reports
Jenkins stores build history and shows trend graphs on the job page. These graphs reveal patterns — a test that fails intermittently, build times growing over weeks, or coverage dropping after a refactor.
Available trend graphs on Jenkins job page:
Build Time Trend:
Shows how long each build took over recent runs.
Spike in duration = something slowing down the build.
Test Result Trend:
Pass/fail/skip counts per build.
Rising failure count = regression introduced.
Code Coverage Trend (with JaCoCo plugin):
Line and branch coverage per build.
Dropping coverage = new code added without tests.
SonarQube Trend (with SonarQube plugin):
Bug count, vulnerability count, code smell count.
Rising counts = quality degrading over time.
HTML Reports with publishHTML
For tools that generate HTML reports (coverage tools, performance test reports, custom reports), use the publishHTML step to host them directly on the Jenkins build page.
post {
always {
publishHTML([
allowMissing: false,
alwaysLinkToLastBuild: true,
keepAll: true,
reportDir: 'target/site/jacoco',
reportFiles: 'index.html',
reportName: 'Coverage Report',
reportTitles: ''
])
publishHTML([
reportDir: 'performance-reports',
reportFiles: 'report.html',
reportName: 'Gatling Performance Report'
])
}
}
After the build, the report appears as a link on the build page:
Build #45
Archived Artifacts
Coverage Report ← Click to view HTML
Gatling Performance ← Click to view HTML
Console Output
Test Results
Notification Best Practices
Channel strategy: #deployments → Successful production deployments only #ci-failures → Every build failure (any branch) #alerts → Critical failures (main/production only) #builds → All build results (useful for small teams) Who gets notified: Email the person whose commit broke the build (not the whole team) Slack the team channel for shared awareness Page on-call only for production incidents Avoid notification fatigue: Do not send email on every successful build Do send on: failure, recovery, unstable Rate-limit repeated failures from the same job
Key Points
- Email Extension plugin provides rich, customizable emails with attached logs and HTML templates.
- Slack notifications deliver instant build results to team channels with color-coded status.
- GitHub and GitLab status checks show build results directly on pull requests, blocking merges on failure.
- publishHTML hosts coverage, performance, and custom reports directly on the Jenkins build page.
- Avoid notification fatigue by routing messages to the right channels and notifying on failure/recovery, not every success.