Atlassian Jira Monitoring on Microsoft SCOM
As part of a customer project, we developed a custom Jira Management Pack for Microsoft System Center Operations Manager (SCOM). This tailored solution enables IT operations teams to monitor key performance and health metrics of Jira environments, ensuring planning and bug-tracking platforms remain available and performant.
With this Use Case paper, we want to share our knowledge with the SCOM Community to highlight the possibilities of advanced monitoring on Microsoft SCOM, helping teams get better in their day-to-day tasks.
What is Jira by Atlassian
Atlassian Jira is a powerful project and issue tracking platform widely used for software development, IT service management, and business workflow automation. It enables teams to plan, track, and release projects efficiently using agile methodologies like Scrum or Kanban.
Why Monitor Atlassian Jira?
Monitoring Jira is essential to ensure high availability, performance, and reliability of the system, which often serves as a critical hub for daily operations. Proactive monitoring helps detect issues such as slow response times, failed background jobs, database or integration errors, and resource bottlenecks, minimizing downtime and ensuring a seamless user experience for developers, support teams, and business users alike.

Want to chat about building your next Management Pack?
Key Atlassian Jira Monitoring Areas
Ensure performance, availability, and security in your Jira environment by tracking key technical indicators. Below is a breakdown of what IT teams should keep an eye on to proactively detect issues, optimize system health, and support uninterrupted collaboration.

Application Performance
Monitor these metrics to ensure Jira remains fast, stable, and responsive for users under varying loads.
Page Load Times: Time to load dashboards, issue views, and boards, as slow page loads directly impact user experience and can indicate backend or DB issues.
API Response Times: Especially for integrations (e.g., CI/CD, scripts, external tools), as delays in API responses can disrupt automated workflows and tool integrations.
Throughput: Requests per second, issues created/updated per time unit helps assess load trends and system capacity under typical and peak conditions.
Error Rates: HTTP 4xx/5xx errors, plugin failures, or exceptions in logs, as spikes in error rates are often early indicators of system degradation or misconfigurations.
Slow Queries: Database query latency (especially for large Jira instances) identifies inefficient queries that may cause timeouts or UI slowness.
Thread Pool Metrics: Stuck threads or long-running threads can cause application hangups or delayed task processing.
Garbage Collection (GC) Stats: For JVM tuning (heap size, GC pause time), as excessive GC activity can lead to latency spikes or memory exhaustion.

Availability
Ensure Jira remains accessible, operational, and within resource limits to avoid outages or user disruptions.
Uptime: Is Jira accessible from multiple geographical regions? Monitoring uptime ensures availability and helps detect location-specific access issues.
Health Endpoints: Status of internal Jira services (e.g., mail queue, indexing, plugins) provides insight into whether essential internal services are functioning properly.
Database Connection Health: Connection pool saturation or failures can halt Jira’s ability to read/write data, resulting in downtime.
Disk Space: Free disk space for attachments, logs, and backups, as running out of disk space can corrupt data, block uploads, or crash the service.
License & User Limits: Nearing user or project limits, which can block functionality, as exceeding license thresholds can lock users out or block new project creation.
Background Jobs: Status of re-indexing, email notification jobs, or import/export tasks, as failed or stuck jobs can lead to missing search results, unsent notifications, or failed imports.

Security
Security monitoring helps detect misuse, unauthorized access, and vulnerabilities before they become incidents.
Login Attempts: High volume or failed login attempts could indicate brute-force attempts to help detect suspicious authentication activity that may signal a security threat.
Permission Changes: Track changes to global/project-level permissions or group memberships, to ensure unauthorized users aren’t gaining access to sensitive projects or features.
Audit Logs: Changes in configurations, plugin installations, and administrative activities are critical for compliance and post-incident investigations.
Vulnerable Plugins: Use of outdated or known-vulnerable plugins or apps from the Atlassian Marketplace, as this prevents exploitation of known security flaws through third-party components.
Access from Unusual Locations: Geographic anomalies in user access, as this indicates possible compromised accounts or unauthorized remote access.
User Account Activity: Inactive accounts suddenly becoming active, and privilege escalations can be a sign of internal misuse or an attacker exploiting dormant credentials.
Monitoring Jira Cloud vs Jira Server/Data Center
Monitoring Jira Cloud and Jira Server/Data Center involves different approaches due to differences in infrastructure control, access to internals, and deployment models.
For Jira Cloud, focus on external monitoring (APIs, front-end load times, usage patterns, and logs via UI). For Jira Server/DC, combine infrastructure monitoring (CPU, memory, DB) with application-level observability.
Comparison Table: Cloud vs Server/Data Center
Feature | Jira Cloud | Jira Server/Data Center |
Infra Monitoring | ❌ Not accessible | ✅ Full control |
JVM/GC/Heap Stats | ❌ Not available | ✅ Full access |
Audit Logs | ✅ Limited (Premium+) | ✅ Full & customizable |
API Rate Limits | ✅ Monitor via HTTP headers | ❌ No hard limits |
Uptime Checks | ✅ Via synthetic checks | ✅ Via local/remote monitoring |
App Performance (Custom) | ❌ Limited | ✅ Deep profiling possible |
Log Access | ❌ No access | ✅ Full log access |
Plugin Vulnerability Checks | ✅ Marketplace-managed | ✅ Must manage manually |
Cluster/Node Monitoring | ❌ N/A | ✅ Hazelcast & node status |
Third-party Monitoring Tools | ✅ Limited (API-based only) | ✅ Full (JMX, SNMP, OS-level) |
Jira Cloud Monitoring
In Jira Cloud, Atlassian hosts and manages the infrastructure. You’re limited to what Atlassian exposes via APIs, logs, and admin interfaces. You can’t monitor the underlying OS, JVM, or database directly.
Application Performance
API Monitoring: Use tools like Postman monitors, New Relic Synthetics, or custom scripts to test Jira REST API latency and error rates. Watch rate limiting responses (HTTP 429
).
End-User Performance (Synthetic Monitoring): Browser-based tools (e.g., Pingdom, Uptrends, or RUM tools like Datadog RUM) to track page load times and JavaScript performance.
Availability
Status Page: Use Atlassian’s Jira Cloud Status Page to monitor outages and maintenance windows.
Health Checks: Periodically ping the login page, dashboards, and important project URLs.
Third-Party Synthetic Checks: Pingdom, UptimeRobot, or AWS CloudWatch Synthetics for uptime checks.
Security
Audit Logs: Use the Admin Audit Log to track changes to permissions, users, apps, workflows, and security settings. Available in Premium/Enterprise tiers.
Atlassian Access: Provides centralized monitoring for user access, SSO, failed logins, and suspicious activity across all Atlassian Cloud products.
OAuth/API Token Management: Monitor personal access tokens and third-party integrations.
Jira Server / Datacenter Monitoring
In Jira Server or Data Center, you host the infrastructure, so you have full access to logs, JVM, OS metrics, and databases. This enables deeper and more customizable monitoring.
Application Performance
JVM Metrics: Monitor heap usage, garbage collection, thread pool stats.
Slow SQL Queries: Enable SQL logging (slow-query-log
) or use database-side tools (e.g., pg_stat_statements for PostgreSQL).
Thread Dumps: Periodically take thread dumps to monitor for thread starvation or deadlocks.
Indexing and Job Queues: Monitor background job delays (e.g., re-indexing, email queue processing).
Availability
Application Health Checks: Atlassian provides internal /status
and /rest/api/2/serverInfo
endpoints.
Clustering (Data Center only): Hazelcast status, node availability, replication lag.
Service Ports and Process Monitors: Monitor Tomcat (HTTP/HTTPS), database connections, and mail queues.
Disk Usage: Track space for attachments, backups, and logs.
Security
Log Monitoring: Parse atlassian-jira.log
, access.log
, and catalina.out
for brute-force attempts, error spikes, and suspicious access.
Audit Logs: Local audit logs provide high-detail monitoring of config and permission changes.
SSO/LDAP Monitoring: Watch for authentication failures or changes in directory syncs.
Vulnerability Scanning: Periodically scan with Nessus, OpenVAS, or Qualys for CVEs, especially plugin vulnerabilities.
Custom Scripts: Use scripting (Shell/Python) for proactive checks on permissions, orphaned users, etc.
Jira Monitoring – Key Technical Areas for SCOM Admins
These are the most important aspects to consider when monitoring Atlassian Confluence from the perspective of a Microsoft System Center Operations Manager (SCOM) administrator.
Windows/Linux Host Monitoring
CPU usage: Alert on sustained high CPU (Jira is Java-based and CPU-intensive during indexing, plugin loading, etc.). This identifies performance bottlenecks caused by Jira’s high CPU demands during indexing or plugin operations.
Memory usage: Monitor both system memory and process-level memory (JVM heap size if possible). This ensures sufficient memory is available to avoid crashes, slowdowns, or OutOfMemoryError
incidents.
Disk space: Key partitions like /var/atlassian
, /opt/atlassian
, /jira-home
, and logs/attachments storage areas. This prevents service outages caused by full disks, which can stop Jira from writing logs, attachments, or indexes.
Disk I/O performance: Especially important for large attachments or log churn. Slow disk I/O can degrade user experience during file uploads, project browsing, and indexing operations.
Network availability: Check connectivity between Jira nodes (if clustered) or to DB/SMTP servers. This verifies critical network paths are up, preventing disruptions in clustered Jira setups or mail delivery.
Log File Monitoring
Files to monitor: atlassian-jira.log
, catalina.out
, access.log
. These contain Jira-specific errors, plugin issues, and access events crucial for troubleshooting.
Patterns to watch: Look for ERROR
, SEVERE
, OutOfMemoryError
, index corruption messages. Catching these patterns early helps prevent prolonged outages or silent failures.
Real-time alerting from logs: This gives proactive visibility into issues that may not surface through standard monitoring.
JVM Monitoring
Heap memory used vs. max heap: Use java.lang:type=Memory
via JMX. This helps avoid memory exhaustion by tracking trends and ensuring the heap is correctly sized.
Garbage collection time: Track GC pause durations with GarbageCollector
beans. This reveals whether GC tuning is needed to prevent application slowdowns due to frequent or long pauses.
Thread count and deadlocks: Monitor java.lang:type=Threading
for total and deadlocked threads. This detects threading issues that could freeze parts of Jira or lead to a full outage.
Class loading trends: Watch for growth in loaded class count via JMX. Sudden increases can point to memory leaks, often due to poorly written or incompatible plugins.
Jira-specific MBeans: Expose custom metrics like index status, mail queue, or cache sizes. This provides insights into Jira’s internal health that are not visible from the OS or UI.
Database Connectivity
DB connection health: Track connection pool usage or test basic DB queries. Loss of connectivity here directly affects logins, issue creation, and nearly all Jira functions.
Slow queries / long transactions: Monitor via SQL logs or DB-side tools. Helps identify inefficient queries or locked transactions that delay Jira operations.
Blocked processes: Detect DB locks and blocks. Unresolved blocking can cause timeouts in the Jira UI or background job failures.
Jira Service Availability
HTTP Availability Checks: Monitor endpoints like /login.jsp
, /rest/api/2/serverInfo
. This confirms the web interface and REST APIs are up and responding to users and integrations.
Port Checks: TCP 8080 (or 8443), database (e.g., 5432), SMTP, etc., ensures Jira and its dependent services are reachable and accepting traffic.
Service Process Monitoring: Monitor java.exe
or Linux service wrapper. This alerts you if the Jira application process crashes or fails to start properly.
Custom SCOM Monitors for Jira
PowerShell/Unix script monitors: Use scripts to hit REST APIs or test configs. This enables deep, custom checks for things like license usage, mail queue status, or active users.
SNMP Traps or Webhooks: Connect Jira to SCOM with middleware or direct integrations. Allows near real-time alerts for key events like failed indexing, node disconnects, or license issues.
Security & Audit Events
Audit logs: Monitor for permission changes, configuration changes, workflow edits. These logs are essential for compliance, change tracking, and spotting unauthorized activity.
Authentication failures: Capture patterns like repeated failed logins. This can indicate brute-force attacks or identity provider misconfigurations.
Group membership or permission changes: Alert on unexpected role escalations. Helps detect and prevent privilege abuse or configuration errors.
Plugin installations or removals: Watch for sudden changes in the plugin ecosystem. Unauthorized or risky plugins can impact Jira stability and security.
OS And Database Matrix
Jira Host OS | Database Type | Key Monitoring Focus (SCOM MP & Script Targets) |
Linux | PostgreSQL | Monitor system service (jira.service) and Java process. Monitor /opt/atlassian, /var/atlassian disk usage. DB port 5432 check, DB availability via queryParse logs (atlassian-jira.log, catalina.out). |
Linux | MySQL/MariaDB | Same as above, but validate connectivity to port 3306. Watch for query failures in logs. Slow query detection if MySQL logging is enabled. |
Linux | MS SQL (remote) | Monitor Linux host as above. Focus on network path to SQL Server (TCP 1433). Watch JDBC errors in logs (SQLServerException) |
Windows | PostgreSQL | Monitor Windows Service (Atlassian Jira or wrapper). Check JVM heap via PowerShell/JMX. Check PostgreSQL as service or remote port. |
Windows | MS SQL | Monitor java.exe process or Jira service. Use native SQL Server MP for DB health. Correlate Jira-side JDBC error logs with SQL blocking data. |
Windows | MySQL/MariaDB | Validate MySQL service and port 3306. Alert on JDBC errors, login failures in Jira logs. Check for stale DB connections. |
Atlassian Jira Monitoring Use Cases
As the backbone of project management, software development, and IT service workflows, Jira is mission-critical for many organizations. Whether used by agile development teams, service desks, or compliance departments, its performance, availability, and usability directly impact business outcomes. Monitoring Jira isn’t just about system uptime, it’s about ensuring teams can work efficiently, maintain compliance, and avoid costly disruptions.
The following real-world use cases illustrate how Jira monitoring helps organizations stay proactive, optimize operations, and support critical business functions.

Preventing Workflow Bottlenecks in a Fast-Paced DevOps Team
Use Case
A fintech startup relies on Jira to manage rapid sprints across multiple agile teams. Each team handles dozens of tickets weekly, with tight delivery schedules and regulatory deadlines. Managers notice that issues are stalling in certain statuses, but don’t have visibility into where the holdups are happening.
How Monitoring Helps
Workflow analytics highlight where tickets spend the most time (e.g., “In Review” or “QA Testing”).
Monitoring alerts the team when issues exceed expected time limits in key statuses.
Custom dashboards track SLA compliance across teams.
Benefits
Ensures deadlines are met without compromising quality or compliance.
Eliminates bottlenecks that delay releases.
Improves collaboration between developers, testers, and product managers.

Ensuring Stability During Large-Scale Migrations
Use Case
An enterprise company is migrating from Jira Server to Jira Cloud. Thousands of users depend on Jira daily for project tracking, incident management, and development work. Any service degradation could halt critical operations.
How Monitoring Helps
System monitoring tools track API usage, database performance, and background jobs in real-time.
Alerts notify IT if there’s a spike in errors or performance degradation.
Usage metrics confirm when teams are successfully using the cloud environment.
Benefits
Builds confidence in the new environment with measurable performance benchmarks.
Minimizes risk of downtime during migration.
Ensures a smooth transition with minimal disruption to users.

Managing Plugin Performance in a Custom Jira Environment
Use Case
A software company has a highly customized Jira instance with several third-party and in-house plugins for automation and reporting. Over time, users report that the system is getting slower, especially when creating or updating issues.
How Monitoring Helps
Tracks plugin response times and identifies which ones cause slowdowns.
Analyzes error logs from custom scripts and integrations.
Helps test plugin performance during upgrades or new releases.
Benefits
Protects system stability by validating plugin performance.
Prevents user frustration from sluggish workflows.
Enables proactive troubleshooting before issues escalate.

Auditing User Access for Compliance in a Regulated Industry
Use Case
A healthcare organization uses Jira to track issues related to patient services and internal IT. Regulatory compliance (e.g., HIPAA) requires strict control over user access and permissions, as well as audit trails for data-related activities.
How Monitoring Helps
Logs all user activity, including permission changes and access to sensitive projects.
Triggers alerts when unauthorized users are added to restricted projects or groups.
Produces exportable audit logs for compliance reviews.
Benefits
Meets industry standards for security and accountability.
Supports audits with verifiable access history.
Reduces risk of data exposure or policy violations.

Optimizing License Usage Across a Global Organization
Use Case
A global tech firm has over 5,000 Jira users but suspects that only a fraction are active regularly. The company wants to ensure it’s not overspending on licenses while still giving teams the access they need.
How Monitoring Helps
Tracks active vs. inactive users over 30/60/90-day periods.
Provides visibility into login patterns by region and department.
Helps identify users who can be deactivated or switched to read-only roles.
Benefits
Supports data-driven decisions on access control and user management.
Reduces unnecessary licensing costs.
Frees up budget for other productivity tools.
We hope this Atlassian Jira Monitoring Use Case paper inspires you to extend your monitoring on Microsoft SCOM. Feel free to reach out for help building your next custom Management Pack.
NiCE Services and Training for Microsoft SCOM
NiCE Services & Training for Microsoft System Center Operations Manager (SCOM) offers specialized expertise in enhancing IT monitoring through the development of custom Management Packs tailored to an organization’s unique infrastructure and business needs.
By leveraging NiCE’s deep knowledge of SCOM, their services empower IT teams to extend native monitoring capabilities, enabling precise, scalable, and efficient oversight of complex environments. The custom management packs crafted by NiCE address specific applications, devices, and services not covered by default SCOM templates, ensuring comprehensive visibility and proactive issue detection.
In addition to bespoke management pack creation, NiCE provides targeted training to equip IT professionals with the skills to maintain, customize, and optimize SCOM environments independently. This combination of tailored solutions and knowledge transfer significantly improves operational reliability, reduces downtime, and maximizes the return on investment in Microsoft SCOM deployments.
