India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP Monitoring and Operations: Basis, HANA and Cloud Run Under One SLA
SAP monitoring and operations is the recurring run of an SAP landscape on cloud: watching HANA, NetWeaver and cloud infrastructure, responding to alerts with runbooks, patching kernels, HANA and OS on a schedule, and managing jobs, transports and capacity. NTSPL runs these under one SLA, combining cloud-native SAP monitoring with SAP Cloud ALM or Solution Manager.
Delivered on
In scope
Why SAP Alerts Need One Catalogue Across Basis, HANA and Cloud
After migration, many SAP teams find their monitoring split across three places: cloud metrics for VMs and disks, SAP CCMS or Solution Manager for work processes and jobs, and HANA cockpit for memory and replication. Each raises alerts, none of them correlates, and the night-shift operator learns of a full log volume from a plant manager whose goods receipts are stuck. Patching is postponed because no one owns the combined kernel, HANA revision and OS cycle.
NTSPL runs SAP operations from a single alert catalogue that maps every signal, from HANA log volume fill and replication lag to SM13 update errors, ST22 dumps, cancelled SM37 jobs and Pacemaker resource failures, to a severity, an owner and a written runbook. Patches follow a quarterly cycle that moves through sandbox, quality and production in a fixed sequence. Monthly reviews cover EarlyWatch findings, capacity trends and SLA performance.
Operating Symptoms That Show SAP Run Processes Need Rework
Signals you need SAP Monitoring & Operations
- Operators receive more than 200 SAP and infrastructure alerts a week and fewer than 10 percent need action.
- HANA revisions or SAP kernels are more than 12 months behind the current patch level.
- Users report problems such as stuck updates or failed jobs before monitoring does, at least once a month.
- Basis knowledge sits with one or two people and night or weekend coverage is informal.
- Solution Manager is ageing and the team needs to plan monitoring on SAP Cloud ALM or a cloud-native stack.
When to choose something else
- The landscape is still being built or migrated; operations takeover starts after hypercare.
- SAP runs under RISE with SAP, where SAP operates infrastructure and Basis; NTSPL then supports customer-side tasks such as integration monitoring and functional job ownership.
- The need is only general cloud monitoring for non-SAP VMs; standard managed cloud operations is enough.
Recurring SAP Operations NTSPL Takes Over
Monitoring and alert response
HANA memory, log volume, backup and replication; NetWeaver work processes, update errors, dumps, locks, queues and jobs; cluster and infrastructure signals, all handled through runbooks.
Patch and release cycle
Quarterly SAP kernel, HANA revision and OS patching through sandbox, quality and production, with cluster maintenance procedures and rollback.
Job, transport and queue operations
Batch job scheduling and failure handling, transport imports per release calendar, and IDoc, qRFC and bgRFC queue monitoring.
Capacity and health reviews
Monthly review of HANA memory growth, disk throughput, CPU, EarlyWatch Alert findings and certificate expiry.
Service management and SLA
Incident, request and change handling with response and resolution targets per severity, and monthly SLA reporting.
How SAP Monitoring & Operations Works, Step by Step
SAP Signal-to-Runbook Pipeline for Day-Two Operations
Signals from HANA, NetWeaver, clusters and cloud infrastructure are collected by cloud-native SAP monitoring and SAP Cloud ALM, normalized into one alert catalogue and routed to on-call staff with runbooks. Patterns feed monthly capacity and EarlyWatch reviews.
Select any component
SAP Signal-to-Runbook Pipeline for Day-Two Operations: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
SAP-Aware Monitoring Services on AWS, Azure and Google Cloud
On AWS, Application Insights discovers HANA and NetWeaver components and sets SAP-specific alarms, while Patch Manager handles OS patches outside cluster maintenance windows.
On Azure, Azure Monitor for SAP solutions collects HANA, NetWeaver, Pacemaker and OS data into Log Analytics, and Azure Center for SAP solutions shows system health per SID.
On Google Cloud, the Agent for SAP sends HANA and NetWeaver metrics to Cloud Monitoring, and Workload Manager runs scheduled checks against SAP best-practice rules.
Operating Model Choices for SAP on Cloud
Cloud-native SAP monitoring or SAP Cloud ALM
Use both for different purposes. Cloud-native SAP monitoring is best for HANA, OS, cluster and infrastructure correlation. SAP Cloud ALM covers business process, job and integration monitoring and is included with SAP Enterprise Support. Keep one alert catalogue across both so operators see one queue, not two consoles.
Patch cadence
Apply OS security patches monthly, SAP kernel and HANA revisions quarterly, and support packages or feature packs once or twice a year. Always run sandbox, then quality with a regression test set, then production two to four weeks later. For HA clusters, patch the secondary first, perform a planned takeover, then patch the former primary.
Alert thresholds
Start from provider and SAP defaults, then tune per SID after four weeks of data. Aim for fewer than 20 actionable alerts per week per production landscape. Keep HANA log volume, backup failure and replication lag at severity one regardless of noise, since they precede data loss.
RACI with functional teams
Basis and infrastructure own platform health; functional teams own job content, master data and business errors. Write which team owns each job class and IDoc message type. Without this, failed jobs bounce between teams for hours and SLA reports become disputes.
Transition into Managed SAP Operations in Six Weeks
Discovery and knowledge transfer
Shadow the current team, collect runbooks, job lists, transport routes and known issues for each SID.
Monitoring and alert catalogue
Deploy cloud-native SAP monitoring, connect Cloud ALM or Solution Manager and build the alert catalogue with runbooks.
Reverse shadow
NTSPL operates with the current team watching, and gaps are fixed before formal takeover.
Takeover and first patch cycle plan
Formal SLA start, on-call rota live and the first quarterly patch calendar approved.
What you receive
SLA and Health Measures Reported Every Month
| KPI | Typical target |
|---|---|
| Severity-one response time | Within 15 minutes, 24x7 |
| Incidents detected by monitoring before users | At least 85 percent |
| Production on supported kernel and HANA revision | No more than one quarter behind plan |
| Actionable share of alerts | Above 60 percent after tuning |
| Failed critical batch jobs resolved before business start | At least 95 percent |
Operational Failure Patterns in SAP Run Teams
| Risk | How NTSPL prevents it |
|---|---|
| Knowledge of custom jobs and quirks leaves with the outgoing team | Two-week shadow and one-week reverse shadow, with every job class and known issue documented before SLA starts. |
| Patching triggers unplanned cluster takeover | Runbooks use cluster maintenance mode and patch the secondary first, with a planned takeover step. |
| Alert fatigue returns after tuning | Monthly review retires alerts with no action in 90 days or rewrites their thresholds. |
Cloud-native SAP monitoring or SAP Focused Run for SAP operations?
SAP Focused Run is built for service providers and very large customers running hundreds of SAP systems, with deep SAP-side analytics, but it needs its own infrastructure and specialist skills. For most Indian enterprises with 5 to 30 SAP systems, cloud-native SAP monitoring combined with SAP Cloud ALM gives the right coverage: infrastructure, HANA and cluster signals from the cloud tool, business process and job monitoring from Cloud ALM, and no extra platform to run. NTSPL recommends Focused Run only when the SAP estate is large enough to justify a dedicated monitoring team.
Key facts: SAP Monitoring & Operations
SAP Monitoring & Operations in Practice
2 SAP Monitoring & Operations scenarios, from Cosmetics and Sanitaryware, plus related platform case studies.
Cosmetics brand catches HANA log fill 40 minutes before stuck invoicing
Sanitaryware maker unifies SAP alerts from AWS, BTP and SuccessFactors in one queue
Telecom VAS provider cuts daily pages from 2,300 alerts to 9 actionable incidents
IT services firm brings 43 Azure subscriptions under one policy hierarchy
SAP Monitoring & Operations: Frequently Asked Questions
What does managed SAP operations cost?
Pricing depends on the number of SIDs, production criticality and coverage hours. A landscape of 3 production systems with their tiers under 24x7 coverage is usually priced as a monthly fee per SID, with patch cycles included. NTSPL quotes after a two-week discovery.
Do you replace our Basis team?
Not necessarily. Some clients hand over full Basis and cloud operations; others keep an internal Basis lead for design decisions and use NTSPL for 24x7 monitoring, patching and night shifts. The RACI is written before takeover.
How do you handle SAP patching during peak business periods?
We agree a freeze calendar with business owners covering month-end, quarter-close, GST filing weeks and seasonal peaks. Emergency security patches can still be applied with change approval, but planned cycles avoid those windows.
Are operations logs kept in India?
Yes. Monitoring data, alerts and operations logs are stored in Indian regions and retained for at least 180 days, supporting CERT-In directions and providing evidence for incident reporting within 6 hours.
What happens with SAP Solution Manager?
If you use Solution Manager today, we integrate with it. For new monitoring scope, SAP Cloud ALM is SAP's direction, so NTSPL plans a staged move of job, integration and business process monitoring into Cloud ALM.
Do you cover SAP BTP and integration monitoring?
Yes for monitoring and first response. Cloud ALM integration monitoring covers Cloud Integration flows and interfaces, and our runbooks route failures to the integration owner with context.