Introducing Farrenio Cloud Control: your whole SAP estate in one console

Most SAP Basis teams run more systems than they can comfortably watch. Four people, a dozen SIDs, and a monitoring answer that involves opening a SAPGUI window per host. It works, in the sense that the systems stay up — but the cost is paid in mornings spent checking things that were fine, and in the occasional problem nobody saw because it was growing quietly on the one system nobody had open.

Farrenio Cloud Control is the platform we built for that job: every SAP system, its Basis transactions, its HANA tenants, its host layer, its alerts and its audit trail, in one browser console. This post is the written tour — what it watches, what it can run for you, how it connects, and where the honest limits are.

The problem it is actually solving

Generic infrastructure monitoring already covers CPU, memory and disk, and it covers them well. What it does not know is that SM50 shows every dialog work process in PRIV mode, that ST22 collected forty TSV_TNEW_PAGE_ALLOC_FAILED dumps in an hour, that a SM37 chain finished with status cancelled at 02:14, or that a HANA delta merge has not run on the table that matters. Those signals live inside SAP, and until you look at them you are watching the box rather than the system.

So the design constraint was narrow and specific: read the SAP layer with the same fidelity a Basis person gets from SAPGUI, put it next to the host and database layers, and make it cross-system by default. One question, one screen, every SID — not one screen per SID.

How it connects — and why security signs it off

A lightweight Python collector runs on each SAP host. It talks to the local system the way an operator would — RFC into ABAP, sapcontrol for the instance layer, SQL against HANA where it is licensed, and the OS underneath — then pushes what it gathered outbound over HTTPS on 443. Nothing connects into your landscape. There is no inbound firewall rule to negotiate, no VPN tunnel to keep alive, no bastion host, and no SAPGUI install on the laptop of whoever is on call.

Deployment is a script and a token. The agents then report their own health on a 30-day timeline, so a collector that goes quiet is itself an alert — a monitoring system that silently stops monitoring is worse than none, and the fleet view exists precisely to make that impossible to miss.

What it watches

The point of putting them on one page is correlation. A response-time spike in ST03 next to a filesystem at 96% next to a transport imported forty minutes ago is a diagnosis. The same three facts in three different tools is an afternoon.

From signal to evidence

Thresholds are per metric, per system, per customer — the batch window that is normal on one system is an incident on another, and a single global rule set guarantees you either miss things or train people to ignore the noise. When a rule fires, it reaches the channel your team actually reads: email, Slack, Teams or PagerDuty, with severity-based escalation for the ones that cannot wait, and maintenance windows that suppress the noise you scheduled yourself.

An alert that matters becomes an incident with an owner, a severity and a comment thread, and it stays one object until it closes. That is what makes the availability number at the end of the month defensible: uptime is computed per system with planned maintenance excluded, rolled up across customers, and exported to PDF or Excel when the SLA review comes around. Nobody reconstructs the timeline from a chat scrollback.

The work it can run for you

Watching is half the job. The other half is the routine that has to be done correctly every time and does not benefit from a human retyping it: client copies with SCCL, deleting a client with SCC5, instance start and stop over sapcontrol, kernel patching, system refreshes, and SPAM/SAINT add-on imports. These run as guided procedures — prerequisites checked first, SAP steps in the right order, every step written to the audit trail with the operator's name and source IP.

The deliberate line: these are deterministic runbooks with a human starting them, not autonomous agents deciding to act on production. We wrote about where machine assistance genuinely helps a Basis team and where it is still hype — the short version is that anomaly detection and capacity forecasting earn their place by removing false alarms and flagging the slow, linear problems humans are worst at, while the decision to change something on PRD stays with a person who is named in the log.

Who is allowed to see and do what

Access is a 92-permission matrix across eight built-in roles — platform owner, admin, customer admin, customer, technician, service desk, contractor and support agent — and every permission is delegatable from a UI, so carving out a custom scope does not require a code change. A service-desk user can triage alerts and dumps all day without the ability to touch a transaction or reveal a token.

Underneath: TOTP multi-factor on any account, SSH and RFC credentials encrypted at rest, every privileged action on an append-only audit trail, and every sign-in recorded with IP and device. Audit retention runs 365 days on authentication events and 180 on the rest, and the log is available over an API your SIEM can pull. Multi-tenant deployments keep each customer's data and audit isolated, which is the part that matters if you are a partner watching several clients from one console.

What it is not

• Not a SAPGUI replacement. It covers the operational transactions a Basis team lives in. Configuration, development and the long tail of SAP still belong in the GUI.
• Not an APM tool. It will tell you a response time degraded and what else moved at the same moment. It will not trace a single ABAP call stack for you.
• Not autonomous remediation. Automation runs what you defined, when you start it or when you scheduled it. It does not decide on its own to restart production.
• Not priced per seat. Pricing is per system — one SID, one landscape of up to six, or an enterprise estate scoped against your real inventory. Add as many users as the team needs.

Seeing it on your own systems

There is a screen-by-screen guided tour if you want the visual version of this post — the real console, one capability per slide. Beyond that, the fastest way to judge a monitoring platform is to point it at a system you already have opinions about: connect a collector to one SID and see your own SM37 jobs, ST22 dumps and HANA tenants in the console within minutes, then decide whether the view is worth having across the rest of the estate.

If you run SAP and recognise the morning described at the top of this post, write to contact@farrenio.com and we will set it up against a system of your choosing.