Complete Guide to SAP BASIS Monitoring in 2026
Everything you need to know about modern SAP BASIS monitoring: from SM50 work processes to HANA memory management.
15 May12 min read
Keep your SAP systems UP.
Monitoring of SAP systems, built for Basis teams
The transactions you actually use, read over RFC. Alerts that arrive with the context to understand what happened. And a NIS2/DORA module that produces a report you can sign.
- On-premise, inside your network
- No agents on SAP systems
- Read-only users
- Italian and English interface
ALERT03:41
[SUPtime] PRD · ST22 short dumps above threshold
- ABAP SID
- PRD
- DB SID
- HDB · SAP HANA
- Release
- SAP_BASIS 758 · kernel 793
- Landscape
- Production · Rossi SpA
- Rule
- ST22 dumps > 0 in 15 min
First occurrences
| Time | Error | Program | User |
|---|---|---|---|
| 03:38 | TIME_OUT | ZFI_POST_BATCH | BATCH_FI |
| 03:40 | TSV_TNEW_PAGE_ALLOC_FAILED | ZSD_BILLING_RUN | RFC_SD |
| 03:41 | TIME_OUT | ZFI_POST_BATCH | BATCH_FI |
RECOVERED04:12 · condition cleared on PRD
What it monitors
The transactions you know, read over RFC
Every tab maps to a transaction a Basis admin knows. Data comes straight from the system, not from an intermediate store, and stays in SAP's own form: work process states, DIA, the E, W, S and I letters.
Availability
sapcontrolICM
A probe every 60 seconds, no credentials: up, degraded or down status, SLA over 24 hours/7/30 days with declared coverage.
Security
SM20
Security Audit Log: successful and failed logons, user administration, started transactions and RFC calls.
Jobs and updates
SM37SM13
Job status and duration, long-running and late jobs, and broken periodic chains. Terminated and pending update records.
IDoc
WE02BD87
Failed and stuck IDocs, from the EDIDC headers alone. Errors and waits older than seven days are backlog: counted and shown, never an alarm.
RFC queues
SM58qRFC
The real state of the outbound and inbound queues, with the tRFC states SAP actually uses: SYSFAIL, CPICERR, ANORETRY.
Dumps and logs
ST22SLG1
Short dumps with type, program and user. Application logs filtered by outcome.
Locks and spool
SM12SP01
Exclusive and long-running locks. Spool requests and their outcome.
Transports
STMS
Import queue, errors and transport destinations.
Certificates
STRUST
Every PSE the system lists, not just the well-known ones: for each, its own certificate and the trusted ones, with issuer, expiry and days left. An alert warns 1 to 365 days before they expire, not after.
Load and instances
SM50SM66SM51AL08ST03NSMLG/SDF/SMON
Work processes, instances, dialog sessions, workload analysis, logon groups and performance monitor.
Operating system and memory
ST06ST02
For every application server: filesystems, CPU and load average, memory, swap and paging. Plus extended memory, heap, roll and paging area, and the buffers with hit ratio and swap. Read over RFC, with nothing installed on the host.
SAP HANA
SQL
Load, slow queries, largest tables, backups and disks. Deeper: statistics server alerts, replication, license, delta merge, log and savepoints, tables near the row limit per partition and out-of-memory events.
Oracle
SQL
Load, slow queries, largest tables, RMAN and BR*Tools backups, tablespaces as a percentage of their maximum with autoextend. Deeper: server-generated alerts, archiver and redo logs, blocked sessions, the state of the monitoring user. From 10.2 onwards.
XS runtime
XS Classic
Applications, activation errors, sessions and jobs. On XS Advanced it says so, instead of showing zero.
Supported databases: SAP HANA and Oracle. CSV and Excel export for every tab, plus a full report across all areas. Interface in Italian and English, light and dark theme.
Availability
Uptime measured, not inferred
A probe on sapcontrol and ICM checks every system every 60 seconds, with no credentials. The SLA also states how much SUPtime actually observed: monitoring that stopped never turns into 100% uptime.
Last 30 days
- up
- Every instance GREEN and ICM answering.
- degraded
- Something answers, but not everything is green.
- down
- Sapcontrol and ICM silent, or the ABAP instance stopped.
- not measured
- SUPtime was not watching: the gap is declared, never counted as SAP downtime.
Declared SLA
- 24 hours
- 100%100% coverage
- 7 days
- 99.86%99.2% coverage
- 30 days
- 99.71%98.7% coverage
- Monitoring that stopped says so
- On restart SUPtime spots the gap between the last check and now, and writes "Monitoring stopped for N minutes" into the history. Whoever comes back states how long they were away.
- A locked user is not a system down
- If sapcontrol answers but RFC or SQL reads fail for three cycles, the status is monitoring_failed and the row gives the reason: usually the technical user, not SAP.
- Sixty seconds, not five minutes
- The probe runs separately from polling: a clean SAP restart takes less than five minutes and would slip between two reads.
- Planned downtime is declared first
- A maintenance window opens before it starts, lasts at most seven days, and cannot be touched once closed. Checks falling inside it leave the uptime figure, but are declared separately alongside the percentage with nothing excluded at all.
How it reasons
Real numbers, or no number at all
A monitor that shows zero when it failed to read is worse than no monitor: it looks like a healthy system. SUPtime always says what it knows and what it does not.
Not authorized
The user is missing an authorization, and the tab names it: for SM20, for example, the S_RFC group RSAU_LOG.
Not available
The source is missing or switched off on the system, like a Security Audit Log not active in SM19.
Zero events
Read correctly: nothing happened. It is the only case where you see a zero.
Three states that look alike and lead to three different actions.
- UNKNOWN never becomes PASS
- A compliance check that could not be read stays out of the score, instead of inflating a report someone will sign.
- SAP's clock, not ours
- Filters follow the monitored system's time zone, read over RFC: no wrong days between midnight and 2 a.m.
- Stale data is declared
- If the /SDF/SMON collector has stopped, the tab shows the last snapshot and says how old it is.
- No estimates instead of data
- Where SAP does not expose a value over RFC, like licenses or CPU per instance, SUPtime does not invent it: it says it is not available.
Alerts
Alerts that explain what happened
Rules apply to one system, a landscape or all of them, and are evaluated at every poll on any monitor.
- Emails with the ABAP SID and the database SID, release and kernel, landscape and customer, rule and first occurrences.
- A RECOVERED notification when the condition clears: silence never stays ambiguous.
- Configurable cooldown, 60 minutes by default. A recovery does not reset it: a problem that comes back right away still notifies.
- SNMP traps alongside email, rule by rule: one when it fires and one when it clears, carrying the same event key, so the NMS closes the event it opened by itself. SNMPv3 authPriv, v2c for receivers that do not support it.
- Maintenance windows for one system, one landscape or all of them: during planned downtime alerts do not go out, and stay in the history as "In maintenance".
- Operating system and database load thresholds are changed from Settings, not from a configuration file: they apply at once to the tabs, the rules and the emails, and the change lands in the audit trail.
- Alert history available in the interface.
Optional
AI root-cause analysis
On request, a language model suggests the likely causes of an alert. Every piece of evidence is checked against the collected data, and what cannot be verified is discarded. The module is off by default.
The life of an alert
- 03:38
Condition met
ST22: 3 new dumps in 15 minutes on PRD.
- 03:41
Email and SNMP trap
With SID, release, rule and the first occurrences.
- 03:41
Cooldown
The same alert is not repeated for 60 minutes.
- 04:12
RECOVERED
The condition cleared: the recovery notification goes out.
What rules are built on
| Monitor | Rows counted | Field compared | Example |
|---|---|---|---|
| SM20 | security audit log events (24 h) | event code, user | AU2 = failed logon |
| SM37 | jobs (7 days) | status, code, outcome | Cancelled |
| JOBS | job findings already evaluated | type, severity, job | cancelled, long_running, late, chain_broken |
| IDOC | IDocs already evaluated (WE02/BD87) | type, severity, status | idoc_error, idoc_stuck |
| RFC | qRFC and tRFC findings already evaluated | type, severity, destination | qrfc_error, trfc_error |
| OS | operating system and memory findings already evaluated | type, severity, application server | filesystem, cpu_load, swap, extended_memory, os_collector |
| DBLOAD | database load above the thresholds you set | type, severity | cpu, memory, connections |
| SM12 | locks | type, mode | E |
| ST22 | dumps (7 days) | type, program | — |
| SP01 | spool requests | status, device | E |
| SLG1 | application logs (24 h) | outcome, object | error |
| SM13 | update records | status, transaction | Terminated |
| STMS | transport queue | status, target system | Error |
| BACKUP | backup and disk findings | type, severity | backup_stale, disk_critical |
| DBTABLE | the size of one table, in MB | table name | BALDAT above 1000 |
| AVAILABILITY | open conditions from the last check | status | down, degraded, monitoring_failed |
| HANA | findings from the HANA tab | type, severity | hana_alert, replication, partition_rows, out_of_memory |
| ORACLE | Oracle health findings | type, severity | server_alert, archiver, blocked_session |
| CERTIFICATES | STRUST certificates: the threshold is the notice in days | PSE | SSLS/DFAULT, 30 days before |
A rule counts the rows matching the value you pick and fires above the threshold. JOBS, IDOC, RFC, OS, DBLOAD, BACKUP, AVAILABILITY, HANA and ORACLE carry rows that are already evaluated: "at least one open issue" fires as soon as there is one and clears by itself when there is none. CERTIFICATES compares the days to expiry with the notice you choose, 1 to 365: critical under 7 days or already expired. The "System unreachable" rule exists from the first start, with no recipients.
NIS2 · DORA compliance
A NIS2 and DORA report to sign, built on system data
The module checks SAP's baseline security controls and produces a Word document ready for signature. It queries production systems, so it is off by default and switched on from Settings.
| Check | Source | What it verifies |
|---|---|---|
| Profile parameters | TH_GET_PARAMETER | Active values, compared with the SAP Security Baseline |
| Standard users | USR02 | SAP*, DDIC, EARLYWATCH, TMSADM and SAPCPIC unlocked |
| Client modifiability | T000 | Production clients that accept changes (SCC4) |
| Certificates | SSFR_GET_CERTIFICATELIST | Expired, or expiring within 30 or 90 days |
| Security Audit Log | RSAUPROF, RSAU_READ_LOG | Active profile, confirmed by the events recorded in the last 72 hours |
The report
- Cover page with a signature line and a score summary.
- Detail per check, with remediation and references to NIS2 art. 21 and DORA art. 9–10.
- Appendix with the raw evidence and the SHA-256 hash of the run.
- States how many checks it could not verify.
Compliance report
NIS2 · DORA
System PRD · client 100 · 2026-09-11
Score3 of 4 compliant
1 not verifiable, left out of the score
- Profile parametersPASS
- Standard usersPASS
- Client modifiabilityPASS
- CertificatesFAIL
- Security Audit LogUNKNOWN
Run hash · SHA-256 7c1e9a04f3b2…d58e
Signature of the person in charge
Security and installation
It stays inside your network, and only reads
SUPtime is installed on-premise on a Linux server and connects to SAP systems over RFC and SQL. Nothing is installed on the SAP systems.
One installation per customer
Different customers' data never share a database: isolation comes from the installation, not from a query filter.
Read-only RFC user
A Z role derived from SAP_BC_BASIS_MONITORING, with S_RFC and table read. The documentation lists every object and why it is needed.
Read-only database user
On HANA only the views and schemas the queries actually use; on Oracle SELECT on the V$ and DBA_ views it needs, nothing more. Never the owner of the application schema.
Encrypted credentials
SAP and SMTP passwords are encrypted at rest, with a key that stays on the server.
Hash-chained audit trail
Logons, system changes, credential access and compliance runs, in a log where tampering becomes detectable.
Roles and sessions
admin, operator and viewer, with authentication on every endpoint. Sessions can be revoked: disabling a user or changing their role signs them out at once, not when their token expires.
Two-factor authentication
MFA optional, required for admins or for everyone, plus a requirement on a single user. Whoever is required sets it up at their next sign-in: nobody is locked out and nobody gets in without it. Remembered devices can be revoked one by one.
Minimum privilege, by choice
sapcontrol and ICM need no credentials, RFC, HANA and Oracle are read-only. A feature that would need more is not built.
It never locks your users
After refused credentials the HANA and Oracle connectors stop retrying for 15 minutes: the database disables a user after a few attempts, and a monitoring tool must not lock itself out.
Database backup
SUPtime's own database is backed up daily, with rotation.
Requirements
- Server
- Linux, 2 vCPU and 4 GB of RAM for about ten systems
- Software
- Python 3.13, MongoDB 7, SAP NW RFC SDK 7.50 or later; Oracle Instant Client only for Oracle releases before 12.1
- SAP systems
- ABAP over RFC; SAP HANA or Oracle over SQL, optional
Pricing
A quote based on your landscape
Tell us how many systems you run and how they are organized: we will send you a tailored proposal.
Tailored
- Every feature, compliance included
- Dedicated on-premise installation
- Italian and English interface
- Installation and user setup documentation
From the blog
Technical notes
Guides and field notes on SAP Basis monitoring, HANA and S/4HANA projects.
S/4HANA Migration: Monitoring Best Practices
Pre-migration checks, cutover monitoring, and post-go-live optimization strategies for successful S/4HANA transformations.
10 May10 min read
Optimizing SAP HANA Memory Management
Practical tips to prevent out-of-memory situations and optimize HANA column store performance.
5 May8 min read
FAQ
Before you install it
How does SUPtime collect data?
Over RFC from the ABAP application servers and, if you provide credentials, over SQL from SAP HANA or Oracle. Polling is automatic and no agent is installed on the SAP systems.
Which authorizations are needed on the SAP systems?
An RFC user with a read-only role, derived from SAP_BC_BASIS_MONITORING plus S_RFC and table read, and optionally a read-only HANA or Oracle user. The documentation lists every object and every grant. SXPG_COMMAND_EXECUTE must never be granted.
Which databases are supported?
SAP HANA and Oracle. On both: load, slow queries, largest tables, backups and volumes, plus health checks (statistics server, replication, license and savepoints on HANA; server alerts, archiver, blocked sessions on Oracle). On HANA also the XS Classic runtime. Oracle from 10.2: releases before 12.1 need the Instant Client on the SUPtime server. The Basis probes over RFC, such as SM20, SM37 and ST22, read the ABAP stack.
Does it warn me before a certificate expires?
Yes. The STRUST tab lists the certificates in the SSL server and client PSEs with expiry and days left, and an alert rule fires 1 to 365 days before, your choice: warning down to 7 days, critical below that or already expired, and it clears when the certificate is renewed. The compliance module, by contrast, judges once a day for the report.
Can I monitor several systems and customers?
Yes. Systems are grouped into landscapes, for example per customer, and alert rules apply to one system, a landscape or all. Different customers each get their own installation, so their data never shares a database.
Where does the data go?
To your server: SUPtime is on-premise. Credentials are encrypted at rest and sensitive access is recorded in a hash-chained audit trail.
What does the NIS2/DORA module cover?
Profile security parameters, standard users, client modifiability, certificate expiry and the Security Audit Log. It produces a Word report with a signature line and the run hash. Data that could not be read never counts as compliant.
Which languages does it speak?
The interface is in Italian and English. Alert emails are in English.
Does it measure uptime?
Yes. A probe on sapcontrol and ICM, with no credentials, checks every system every 60 seconds: up, degraded or down, with SLA over 24 hours, 7 and 30 days. Monitoring coverage is declared, so a gap in SUPtime itself is never mistaken for a gap in SAP.
Contact
See SUPtime on your landscape
Tell us about your SAP systems: we will show you what SUPtime reads and what it needs to read it.
Write to us
Questions, a quote or a technical doubt: write to us and we will reply.
Book a live demo
Pick a date and a time: 30 minutes, with your Basis team's questions.