# SUPtime > SUPtime is on-premise SAP monitoring software for SAP Basis teams, made by SUPtime S.r.l. in Italy. It reads SAP Basis transactions over RFC and SAP HANA or Oracle over SQL, sends alerts that carry the context needed to understand what happened, and produces a signable NIS2/DORA compliance report. The interface is in Italian and English. Tagline: "Keep your SAP UP." The site is bilingual: Italian at https://www.suptime.it/ and English under https://www.suptime.it/en/. Every product statement below comes from the product documentation. ## Key facts - Availability monitoring: a probe on sapcontrol and ICM, no credentials, checks every system every 60 seconds. Up/degraded/down status, SLA over 24 hours, 7 and 30 days with declared monitoring coverage and gaps, a dedicated "system unreachable" alert. Maintenance windows declare planned downtime before it starts (five minutes of tolerance, at most seven days, cancellable while future, closable early while running, immutable once finished, every step in the audit trail): checks inside a window leave availability_percent and are reported separately as planned minutes, minutes down during maintenance, and the percentage with no exclusions. - Basis monitoring over RFC: SM20 (Security Audit Log), SM37 (with deviation from the average duration, long-running and late jobs, broken periodic chains), IDoc from EDIDC headers (WE02/BD87: failed and stuck IDocs, with errors and waits older than seven days counted as backlog rather than alarms), qRFC and tRFC queues (SM58, with the real tRFC states SYSFAIL, CPICERR, ANORETRY), SM12, ST22 (up to 5,000 dumps, marked "N+" when truncated), SP01, SLG1, SM13, STMS, SM50/SM66, SM51, AL08/SM04, ST03N, SMLG, /SDF/SMON. - STRUST certificates over RFC: every PSE the system lists (SSFR_GET_ALL_STRUST_IDENTITIES), and for each one its own certificate (server SSL, SNC, system, logon ticket) as well as the trusted ones, with subject, issuer, expiry and days left, with a CERTIFICATES alert monitor whose threshold is the notice in days, 1 to 365 (default 30): warning down to 7 days, critical below or already expired, clears when the certificate is renewed. An empty read is declared as such, never as "nothing expiring". - Oracle over SQL (10.2 and later; releases before 12.1 need the Oracle Instant Client on the SUPtime server): load, slowest queries, largest tables, backup status from RMAN and from the BR*Tools history (SDBAH), so a SAP running brbackup without RMAN is not reported as having no backup, tablespace usage as a percentage of the maximum with autoextend; Oracle health with a read-only monitoring user (SELECT on the V$ and DBA_ views it needs): server-generated alerts from DBA_OUTSTANDING_ALERTS, archiver destinations and unarchived redo logs, blocked sessions, the state of the monitoring user itself. After refused credentials the connector pauses logons for 15 minutes. - SAP HANA over SQL: service memory, host CPU, slowest queries, largest tables, last backup, data and log disks, blocked transactions, XS Classic runtime (XS Advanced is detected and declared not supported). HANA health, all with the standard MONITORING role: statistics server alerts with SAP's own explanation, system replication status (or "not configured"), license expiry, failed delta merges, unfreed log segments, savepoint critical-phase duration, tables approaching the 2^31 row limit per partition, out-of-memory events, unloads forced by low memory, and the state of the monitoring user itself. - Alerts: rules per system, per landscape or global; RECOVERED notification when the condition clears; 60-minute cooldown by default; English emails with ABAP SID and database SID, release, kernel, landscape, customer, rule and first occurrences. Each rule can also send SNMP traps to an NMS (Nagios, Icinga, Checkmk via snmptrapd): suptimeAlertTriggered when it fires and suptimeAlertRecovered when it clears, carrying the same event key so the NMS closes its own event; SNMPv3 authPriv by default (SHA family, AES-128/256), v2c for receivers without v3, a downloadable SUPTIME-MIB, and an optional suptimeHeartbeat trap as a freshness check on SUPtime itself. Optional AI root-cause analysis, off by default, that discards evidence it cannot verify against collected data. Rules are built on seventeen monitors: SM20, SM37, JOBS (job findings: cancelled, long_running, late, chain_broken), IDOC (idoc_error, idoc_stuck), RFC (qrfc_error, qrfc_attention, qrfc_stale, trfc_error), SM12, ST22, SP01, SLG1, SM13, STMS, BACKUP (backup and disk findings), DBTABLE (the size of one table in MB), AVAILABILITY, HANA, ORACLE and CERTIFICATES; a rule counts the rows matching a value and fires above a threshold, except DBTABLE (threshold in MB) and CERTIFICATES (threshold in days before expiry). The "System unreachable" rule exists from the first start. - NIS2/DORA module: five checks (profile parameters against the SAP Security Baseline, standard users SAP*/DDIC/EARLYWATCH/TMSADM/SAPCPIC, production client modifiability SCC4, certificate expiry, Security Audit Log). Output: a Word report with a signature line, remediation, NIS2 art. 21 and DORA art. 9-10 references, raw evidence and the SHA-256 hash of the run. Data that cannot be read is reported as UNKNOWN and never counted as compliant. - Export: every monitoring tab exports to CSV or Excel with the same sections and filters, empty sections stay in the file and say "no rows in the period"; the full Excel report covers all fifteen areas and keeps a failing area as a sheet with the reason. Interface in Italian and English, light and dark theme, sortable columns. - Least privilege as a written rule: no credentials for sapcontrol/ICM, read-only S_RFC groups, the MONITORING role on HANA, SELECT-only grants on Oracle; anything needing more is not built. After refused credentials the HANA and Oracle connectors pause logons for 15 minutes, so the tool never locks the read-only user (HANA disables a user on the sixth attempt). SUPtime's own database is backed up daily with rotation. - Data honesty: tabs distinguish "not authorized", "not available" and "zero events"; filters follow the monitored system's clock; stale /SDF/SMON data is declared; values SAP does not expose over RFC are not estimated. - Deployment: on-premise Linux server, one installation per customer (not multi-tenant), agentless, read-only RFC user and optional read-only HANA or Oracle user, credentials encrypted at rest, hash-chained audit trail, roles admin/operator/viewer. Two-factor authentication with an MFA policy (optional, required for admins, or required for everyone, plus a requirement on individual users): whoever is required sets it up at their next sign-in, so nobody is locked out and nobody gets in without it. Sessions are revocable, so disabling a user or changing their role signs them out immediately instead of at token expiry; remembered devices can be revoked one by one; the last active admin cannot be disabled, demoted or deleted. 2 vCPU and 4 GB RAM cover about ten monitored systems. Requires Python 3.13, MongoDB 7 and SAP NW RFC SDK 7.50+. - Not covered: databases other than SAP HANA and Oracle (no SAP ASE, DB2 or SQL Server), XS Advanced, Java stacks, Fiori app monitoring, custom code analysis, change and test management (ChaRM), business process monitoring, multi-customer dashboards. - Pricing: quote-based, depending on the landscape. Contact: support@suptime.it or the form at https://www.suptime.it/en#contact ## Pages (English) - [Home](https://www.suptime.it/en): what SUPtime monitors, how alerts work, the NIS2/DORA report, security and requirements - [SAP availability monitoring](https://www.suptime.it/en/use-cases/sap-availability-monitoring): sapcontrol and ICM probes, the four states, SLA with coverage and gaps, monitoring_failed - [NIS2 and DORA for SAP](https://www.suptime.it/en/nis2-dora-sap): the five technical checks, their SAP sources, the NIS2 and DORA articles they map to, the profile parameters and their expected values - [SAP HANA monitoring](https://www.suptime.it/en/use-cases/hana-monitoring): system views read, read-only HANA user, statistics server alerts, replication, license, XS runtime - [Oracle monitoring for SAP](https://www.suptime.it/en/use-cases/oracle-monitoring): V$ and DBA_ views read, read-only Oracle user, RMAN backups, tablespaces, server alerts, archiver, blocked sessions, 10.2 and later - [SAP S/4HANA monitoring](https://www.suptime.it/en/use-cases/s4hana-monitoring): which Basis probes matter after an S/4HANA go-live - [Consultancies and MSPs](https://www.suptime.it/en/use-cases/sap-managed-service): one installation per customer, landscapes, alerts, evidence for customers - [SUPtime vs SAP Solution Manager](https://www.suptime.it/en/vs/sap-solution-manager): a fair comparison, including what SUPtime does not do - [Documentation overview](https://www.suptime.it/en/docs): requirements, read-only SAP users, installation steps, security, declared limits ## Pages (Italiano) - [Home](https://www.suptime.it/): monitoraggio SAP per team Basis - [Monitoraggio disponibilità SAP](https://www.suptime.it/use-cases/sap-availability-monitoring): sonde sapcontrol e ICM, i quattro stati, SLA con copertura e buchi - [NIS2 e DORA per SAP](https://www.suptime.it/nis2-dora-sap): i controlli tecnici NIS2 e DORA sui sistemi SAP - [Monitoraggio SAP HANA](https://www.suptime.it/use-cases/hana-monitoring) - [Monitoraggio Oracle per SAP](https://www.suptime.it/use-cases/oracle-monitoring) - [Monitoraggio S/4HANA](https://www.suptime.it/use-cases/s4hana-monitoring) - [Consulenze e MSP](https://www.suptime.it/use-cases/sap-managed-service) - [SUPtime vs SAP Solution Manager](https://www.suptime.it/vs/sap-solution-manager) - [Documentazione](https://www.suptime.it/docs) ## Blog - [Complete guide to SAP BASIS monitoring in 2026](https://www.suptime.it/en/blog/sap-basis-monitoring-guide-2026) - [S/4HANA migration: monitoring best practices](https://www.suptime.it/en/blog/s4hana-migration-monitoring-best-practices) - [Optimizing SAP HANA memory management](https://www.suptime.it/en/blog/hana-memory-management-optimization) - [Custom code remediation for S/4HANA](https://www.suptime.it/en/blog/custom-code-remediation-s4hana)