Use case · Availability
SAP uptime, measured every minute
Two calls per system with no credentials, every 60 seconds: sapcontrol and ICM. The status is measured, not inferred from the fact that some read happened to work.
What it queries
Two ports, no credentials
The methods are the read-only ones every instance already exposes, the same the SAP MMC uses.
| Source | Port | What it tells |
|---|---|---|
| GetSystemInstanceList · GetProcessList | 5NN13 | The state of every instance and of its processes |
| /sap/public/ping | 80NN | Whether the ICM answers HTTP requests |
| Check history | internal | SLA over 24 hours, 7 and 30 days, with coverage and gaps |
States
Four states, not two
"Up or down" is not enough: a system that half answers calls for a different action than one that is off.
up
Every instance GREEN and ICM answering.
degraded
Something answers but not everything is green: a yellow instance, a silent ICM, silent sapcontrol with a live ICM.
down
Sapcontrol and ICM do not answer, or the ABAP instance or the message server are stopped.
unknown
No check on record: never confused with "all good".
SLA
The SLA also reports on itself
A percentage computed only on successful checks would make stopped monitoring look perfect.
Coverage
How many checks were made against how many were expected in the window, with the minutes not measured.
Gaps on the timeline
Unobserved periods show in grey, sized to their duration, with a start and an end.
Monitoring stopped
On restart SUPtime records "Monitoring stopped for N minutes" in the history, with an email if the rule has recipients.
On the dashboard
The 30-day percentage sits next to the system's other indicators.
Planned downtime
Maintenance is declared before, not after
Downtime declared after the fact would just be a way of tidying up the SLA. The rules exist to prevent that.
Before it starts
The window opens in advance, with five minutes of tolerance, for one system, a landscape or all of them. It lasts at most seven days.
It cannot be rewritten
A future window can be cancelled, a running one can only be closed early, a finished one cannot be edited. Creating, cancelling and closing all land in the audit trail with the name of whoever did it.
Alerts go quiet, the history does not
During the window notifications do not go out and stay in the history as "In maintenance". Once it closes, a problem still open notifies straight away, without waiting out the rule's cooldown.
Separate in the SLA
Checks inside the window leave availability_percent, and next to it you get the planned minutes, the minutes down during maintenance, and the percentage with nothing excluded at all.
When it is not SAP
A locked user is not a system down
monitoring_failed
The system answers sapcontrol, but RFC or SQL reads have failed for three cycles: the row says so, and says why.
The usual causes
A locked user, an expired password, refused credentials: problems of the tool, not of the monitored system.
No lockout caused by us
After refused credentials the HANA connector waits 15 minutes before retrying: HANA disables a user on the sixth attempt.
Alerts
The rule is already there
System unreachable
The AVAILABILITY rule exists from the first start, with no recipients: you only add the addresses.
Clears by itself
The rows are conditions already evaluated: the alert clears when the condition goes away.
Emails with context
ABAP and database SIDs, release and kernel, landscape and customer, rule and first occurrences.
FAQ
Uptime and SLA
Are credentials needed to measure uptime?
No. Sapcontrol exposes unprotected read-only methods on port 5NN13, the same ones the SAP MMC uses, and the ICM answers /sap/public/ping. Credentials are only needed for RFC and SQL reads.
How often does it check?
Every 60 seconds by default, with a minimum of 15, separately from the RFC and SQL polling that runs every five minutes. A clean SAP restart takes less than five minutes and would slip between two reads.
What happens if SUPtime is stopped?
On restart it records the gap as "Monitoring stopped for N minutes" and the SLA states the coverage, that is how many checks were made against how many were expected.
Does it tell a stopped system from a locked user?
Yes. If sapcontrol answers but reads fail for three cycles, the status is monitoring_failed and the row carries the reason.
Does planned maintenance ruin the SLA?
Not if you declare it before it starts. Checks inside the window become planned downtime: they leave the availability percentage and are reported separately, together with the percentage computed with nothing excluded. A window cannot be opened after the fact, nor edited once it has closed.
Declared limits
What it does not measure
- Application response times and user experience.
- The operating system: no credentials, no agent installed.
- If sapcontrol and ICM cannot be reached from SUPtime's network, the status stays not measurable and says so.
- Forecasts: the SLA looks back, not forward.
How long was your SAP really up?
We will show you SLA, coverage and gaps on a real system, without touching your users.