Most SAP monitoring evaluations go wrong before the first demo. The team defines requirements at a high level, schedules presentations from three vendors, watches the same polished slides about real-time visibility and intelligent alerting, and then tries to compare platforms that all look broadly similar on paper.
The questions that would actually reveal the differences never get asked, because nobody prepared them. How does the tool behave when a job finishes successfully but wrote application errors to the spool? Can it monitor SAP BTP extensions in the same view as the on-premise ABAP stack? What happens to alert routing when your on-call engineer is on leave and you need automatic escalation?
This checklist is built around those specific questions. Each one is designed to expose a real gap that generic demo scripts tend to avoid. Work through them during vendor discussions, and you will have a much clearer picture of what each platform actually does versus what the marketing describes.
Coverage : what the platform actually monitors ?
Q1 Does it cover every SAP component you run today, including the ones nobody officially owns?
Every vendor will say yes to this question. The follow-up that matters is: ask for a documented list of supported technologies and cross-reference it against your actual landscape. Not your target landscape after the S/4HANA migration. Your current one, with all the legacy components, the BusinessObjects reporting cluster, the older NetWeaver systems, and the custom connectors.
SAP landscapes in production rarely match the clean architecture diagram in the IT strategy presentation. There are usually components that predate the current IT leadership, systems that are technically deprecated but still used by finance, and integrations that nobody wants to touch because they work and the person who built them left three years ago. A monitoring platform that covers S/4HANA and HANA but not SAP BusinessObjects creates a blind spot in a layer that business users depend on daily.
SAP BusinessObjects is a good specific test. Many platforms claim SAP support but only cover the core ABAP stack. Ask directly whether the tool monitors report scheduling, publication status, server node availability, and user session load in BOBJ environments. If the answer is vague, treat it as a no.
| What a good answer looks like: The vendor produces a component coverage matrix without hesitation. It shows specific monitoring depth per technology, not a checkbox grid where everything is marked supported. |
| Red flag to watch for: The vendor says it supports “all SAP technologies” without being able to specify what metrics it collects for each one. General claims without technical specifics are a reliable sign that coverage is shallower than advertised. |
Q2 Is deployment agentless, and what does that mean exactly for your environment?
Agentless is a word that gets used loosely in SAP monitoring. Some vendors mean they use SAP’s own RFC or REST APIs to collect data without deploying additional software on the SAP application server. Others mean they have an agent that runs on a separate collector host rather than on the SAP server itself. These are meaningfully different architectures from an operational standpoint.
True agentless deployment, connecting via standard SAP RFC connections and APIs, has two practical advantages that compound over time. First, there are no transport requests to maintain. Every SAP transport is a change management item that has to go through dev, QA, and production, and in regulated environments that process takes time. Second, when SAP releases a patch or you upgrade your system, the monitoring tool does not break because it has no code installed on the SAP side.
The question to ask the vendor is this: if we run a major SAP kernel upgrade tomorrow, does your monitoring tool require any action on our side before it continues working? If the answer is yes, you have an agent dependency, regardless of what the marketing says.
| What a good answer looks like: Deployment requires creating a technical RFC user with defined authorizations, pointing the collector at the system, and starting data collection. No transport requests, no SAP-side software, no change management ticket required. |
| Red flag to watch for: The vendor mentions transports, SAP-side configuration, or anything that requires a change request in your SAP system to set up or maintain. This creates ongoing overhead that is easy to underestimate at evaluation time. |
Alerting : signal quality and configuration depth
Q3 How are alert thresholds configured, and who sets them?
Out-of-the-box alert thresholds are almost always wrong for your specific environment. This is not a criticism of vendors. It is a structural problem: default thresholds are calibrated for an average SAP system, and your system is not average. It has a specific workload profile, specific batch cycles, specific peak usage patterns that make “80% CPU” mean something completely different at 14:00 on a Tuesday versus at 02:00 on the first Monday of the month.
The relevant questions here are whether thresholds can be set per system rather than globally, whether the tool supports time-based thresholds (different limits during business hours versus overnight batch windows), and whether there is any mechanism to learn or suggest baselines from historical data.
A monitoring platform that requires manual threshold entry for every metric across every system will become technically correct but operationally ignored. The configuration burden will eventually lead someone to apply a global threshold to all systems just to stop the noise, and then you are back to default behavior with extra steps.
| What a good answer looks like: Thresholds can be configured per system and per time window. The tool collects a baseline period before alerting, or at minimum provides baseline data to help administrators set thresholds that reflect actual system behavior. |
| Red flag to watch for: The default threshold configuration is presented as production-ready. Every environment is different. A vendor confident that their defaults work out of the box has not thought carefully about the diversity of SAP landscapes they are selling into. |
Q4 What does the platform do between detecting an anomaly and sending a notification ?
The distance between detecting a problem and sending a useful alert is where most platforms fall short. A raw alert that says “high CPU on PRD” at 03:00 tells the on-call engineer that something is happening. It does not tell them whether this is the same work process saturation that happens every Monday during the MRP run, or whether it is genuinely abnormal. It does not tell them which background jobs were active at the time, whether HANA memory was also under pressure, or whether there are downstream jobs about to miss their window because of the CPU spike.
The question to ask is: show me what an alert looks like when it fires. Not the configuration screen. The actual notification that lands in the inbox or creates the incident ticket. Does it contain the correlated context, or does it just contain the metric value that crossed a threshold?
Alert correlation, grouping related events into a single incident view rather than sending five separate notifications for five symptoms of the same root cause, is the feature that separates monitoring tools that reduce operational noise from the ones that create it.
| What a good answer looks like: Alerts include correlated context: active jobs at time of trigger, recent system events, related metric deviations. Multiple symptoms of the same underlying issue are grouped into a single incident rather than generating separate notifications. |
| Red flag to watch for: The demo shows threshold-based alerts firing independently for each metric. No correlation, no grouping, no context beyond the metric name and value. This is infrastructure alerting applied to SAP, not SAP-aware monitoring. |
Q5 Can it detect application-level errors inside a completed job ?
This is the most specific question on this list and the one most likely to catch a vendor off guard. SAP background jobs can finish with status FINISHED while containing error messages in their spool output. The ABAP program ran to completion, but it logged message type E records along the way, often because the program handles exceptions internally rather than letting them surface as job-level failures.
For financial close jobs, payroll runs, or billing processes, this distinction is critical. A job that posted 9,400 invoices out of 9,500 because the remaining 100 had data issues looks like a successful job in SM37. The discrepancy shows up when a business user reconciles the numbers two days later.
Ask the vendor directly: if a job completes with status FINISHED but its spool log contains message class E records, does your tool alert on that? Ask them to demonstrate it. Many platforms do not have this capability because it requires parsing spool content rather than just reading the job status field, which is significantly more complex to implement.
| What a good answer looks like: The platform reads job spool output, identifies message class E and A entries, and alerts on jobs that finished with application-level errors even when the job status shows FINISHED. This can be shown in a live demo or test environment. |
| Red flag to watch for: The vendor explains that FINISHED status means the job completed successfully. This indicates the tool monitors job infrastructure, not job content. For business-critical batch processes, that gap will cause incidents. |
Background job monitoring : beyond status codes
Q6 Can it monitor job duration against a baseline, not just completion status ?
A batch job that is currently running at twice its normal duration is not a problem yet. It might finish on time. But it is a signal, and catching it while it is still running gives the operations team the ability to investigate before the job’s window closes and before dependent jobs start queueing.
Duration-based alerting requires the platform to know what normal looks like for each job. That means it needs to store historical runtime data and use that data to flag deviations. It also means it needs to handle legitimate duration variations: the same job that runs in 40 minutes on a normal day might run for 90 minutes at month-end because the data volume is three times higher.
Ask how the tool establishes duration baselines. Does it use a rolling average? Does it allow separate baselines per time period (month-end versus normal days)? Can thresholds be configured as a percentage of baseline rather than a fixed time limit? A platform that can only alert on “job running longer than X minutes” requires constant manual recalibration as business volumes change.
| What a good answer looks like: The tool tracks historical job duration, establishes per-job baselines, and alerts when current runtime deviates significantly from that baseline. Thresholds are expressed as a percentage of baseline duration rather than absolute values. |
| Red flag to watch for: Duration monitoring is only available as a fixed time threshold. The vendor asks you to define a maximum acceptable runtime for each job. This is operationally correct but creates a maintenance burden as volumes change, and it does not adapt to legitimate variation patterns. |
Integration with your existing tooling
Q7 How does it integrate with your ITSM platform, and what does the ticket look like ?
Native ITSM integration is a standard claim. What varies substantially between platforms is the quality of the ticket content that gets created. An integration that opens a ServiceNow incident with the subject line “SAP Alert: High CPU” is technically an integration. An integration that opens an incident with the affected system name, the specific metric and its current value, the correlated events that occurred in the same time window, the recommended investigation steps, and a direct link to the relevant SAP transaction is a tool that actually helps.
Ask for a live example of what an automatically-created incident ticket looks like. Specifically ask about SAP-specific context: does the ticket reference the affected SID, the transaction or job name, the work process type, the relevant log entries? A generic IT alerting integration treats SAP as any other monitored system. A SAP-aware integration creates tickets that an SAP Basis engineer can act on without first having to re-investigate everything from scratch.
Also ask about bi-directional integration. When the incident is resolved in ITSM, does the alert status update in the monitoring platform? When a maintenance window is opened in the monitoring platform, does it suppress incident creation in ITSM for the duration? These two-way behaviors are the difference between an integration that saves time and one that creates double-handling.
| What a good answer looks like: The demo shows an actual generated ticket with SAP-specific fields: SID, component, metric context, recent events, and a recommended action. The integration is bi-directional. Maintenance windows suppress ticket creation automatically. |
| Red flag to watch for: The integration sends a generic webhook payload to ITSM. The vendor explains that the ticket template is configurable by your team. Configurable means not done. You will own the integration quality, not the vendor. |
Deployment and operational overhead
Q8 How long does it take to go from installation to meaningful production monitoring ?
Time-to-value is the metric that vendors are most incentivized to understate during evaluations. The demo runs against a pre-configured reference environment where everything is tuned and every dashboard looks perfect. Your production onboarding will look different.
Ask for a reference timeline from a comparable customer deployment, ideally with a similar number of systems and a similar landscape complexity to yours. Ask specifically how long the baseline collection period takes before alerting is reliable. Ask how threshold tuning is handled during the first weeks when the system is still learning normal behavior. Ask who is responsible for that tuning work: the vendor, your team, or a shared process.
A tool that requires six months of professional services engagement before it stops generating false positives is not a monitoring platform. It is a consulting engagement with monitoring software attached. The onboarding process should be measured in weeks, and your team should be able to run it with vendor documentation rather than vendor presence.
| What a good answer looks like: The vendor describes a structured onboarding process with a defined timeline: system connection in days, baseline collection over two to four weeks, threshold review and tuning, and a go-live sign-off. Reference customers with similar landscape complexity are available to discuss. |
| Red flag to watch for: The vendor mentions a “tailored implementation” or a professional services package as the standard onboarding path. Implementation complexity that requires bespoke professional services usually means the tool is not designed for efficient deployment across diverse SAP landscapes. |
Q9 How does it handle hybrid environments where some systems are on-premise and others are in RISE with SAP or a hyperscaler ?
This question has become more relevant as SAP’s RISE with SAP programme accelerates enterprise cloud adoption. The monitoring challenge in a hybrid landscape is not just technical coverage. It is unified visibility: seeing an on-premise NetWeaver system and a RISE-hosted S/4HANA instance in the same view, with correlated events between them when a business process spans both.
RISE with SAP specifically deserves a dedicated question, because the shared responsibility model creates an ambiguity that many customers have not fully mapped. SAP manages the infrastructure and the platform in RISE. The customer owns the application configuration, the extensions, the integrations, and critically, the observability. The monitoring platform you choose needs to work within the RISE connectivity model without requiring SAP to open infrastructure access that falls outside the standard service scope.
Ask the vendor whether they have production deployments in RISE with SAP environments. Ask how connectivity to the S/4HANA instance is established. If the answer involves any non-standard connectivity request to SAP, that is an adoption risk. A platform that connects via standard RFC using a dedicated monitoring user should work in RISE without any special arrangement.
| What a good answer looks like: The vendor confirms production deployments in RISE with SAP environments. Connectivity uses standard SAP RFC with a dedicated monitoring user, no special infrastructure access required. Hybrid landscapes show on-premise and cloud systems in the same consolidated view. |
| Red flag to watch for: The vendor is vague about RISE compatibility or describes a “planned roadmap item” for cloud support. If hybrid cloud is part of your landscape now or within the next 18 months, this is a disqualifying gap. |
Reporting, resilience, and total cost
Q10 What does reporting look like for people who are not SAP Basis engineers ?
SAP monitoring is often evaluated exclusively by the technical team that will use it day to day. The reporting needs of other stakeholders, specifically the IT director who needs to report on service levels, the business process owners who need confirmation that their critical processes completed, and the MSP account manager who needs client-facing data, are rarely on the requirements list.
A good monitoring platform supports multiple reporting modes. Technical dashboards for the Basis team. Service-level views for operations management. Business process health summaries for the people who own the processes, not the infrastructure. If a platform can only show raw metric data in an interface that requires SAP knowledge to interpret, its reporting value is limited to the smallest audience in the organization.
Ask for a demo of the reporting layer from a non-technical perspective. What would the head of finance see if they logged in? Can a report be generated that shows whether the three most critical financial processes completed within their SLA windows last month? Can that report be automated and sent by email? If the answer to any of those questions is no, the platform is a tool for the Basis team, not for the organization.
| What a good answer looks like: The platform has role-based dashboard views. Non-technical stakeholders can see business process completion status, SLA compliance trends, and availability summaries without interpreting technical metrics. Scheduled reports can be distributed by email automatically. |
| Red flag to watch for: Every view in the demo requires knowledge of SAP metrics to interpret. The vendor positions this as a feature (technical depth) rather than a limitation. Monitoring that only serves the technical team will have limited organizational support when budget renewals come around. |
Q11 What happens when the monitoring tool itself has a problem ?
This question makes vendors visibly uncomfortable, which is exactly why it is worth asking. Monitoring infrastructure fails. Collectors go offline. Database connections drop. The monitoring database fills up. And in each of those scenarios, the question is whether the monitoring system detects and reports its own failure, or whether the only way you discover it is when you notice that a dashboard has not updated in six hours.
Self-monitoring is a basic requirement that is not universal. The monitoring system should alert when its own components are degraded, when data collection has stopped for a specific system, or when alert delivery has failed. It should have a documented recovery process for collector failures. And ideally, it should have some form of redundancy for high-availability environments where monitoring continuity is itself part of the SLA.
Ask the vendor: if your collector loses connectivity to our SAP system at 02:00, how do we find out? If the answer is “you would see gaps in the data,” that means the answer is: you would not find out until you manually checked. That is not self-monitoring. That is absence of evidence.
| What a good answer looks like: The platform has self-monitoring capabilities: it detects collector failures, data collection gaps, and alert delivery failures, and it notifies the operations team when any of these occur. Collector redundancy or automatic failover is available for critical environments. |
| Red flag to watch for: The vendor has not been asked this question before during an evaluation, or answers it by describing disaster recovery procedures for the monitoring database. Data recovery and operational self-monitoring are different capabilities. The latter is what matters for day-to-day operations. |
Q12 How does pricing scale as your landscape grows, and what is included in the base price ?
SAP monitoring pricing has more variation than most enterprise software categories, and the variation is not always visible in the initial quote. The most common structural pricing model is per monitored SID, which is transparent and predictable. The traps are in what is included at the base tier and what becomes a separately priced add-on.
Common add-on costs to ask about specifically: ITSM connectors (ServiceNow, Jira, BMC Remedy) priced per integration, historical data retention beyond a default window, non-production system monitoring at a different rate, and access to specific features (custom dashboards, API access, spool monitoring) gated behind higher pricing tiers.
Also ask what happens at renewal. A per-SID model where production systems cost X and non-production cost less than X is straightforward. A model where the price is per metric collected, or where pricing changes based on data volume, creates uncertainty that compounds as your landscape grows. Get the full pricing model in writing before starting a proof of concept, not after you have already invested three months in evaluation.
| What a good answer looks like: Pricing is per SID with a clear distinction between production and non-production rates. The base price includes core monitoring features without requiring additional modules for standard ITSM integration or data retention. Renewal pricing is contractually defined. |
| Red flag to watch for: The pricing conversation is deferred to a separate commercial discussion. Or the initial quote is for the platform only, with connectors and advanced features as separate line items that only emerge after the initial proposal. |
The 12 questions at a glance
Use this summary as a reference during vendor conversations. The core test column is the single thing each question is trying to establish.
| # | Question | Core test |
| 1 | Does it cover all SAP components you actually run? | Ask for a list. Not a sales deck. |
| 2 | Is deployment agentless? | Agents = hidden maintenance cost at scale. |
| 3 | How are alert thresholds set? | Per-system baselines, not global defaults. |
| 4 | What does it do after an alert fires? | Look for root cause correlation, not just notification. |
| 5 | Does it read spool output and application errors? | FINISHED status is not enough. |
| 6 | Can it monitor background job duration, not just status? | Duration drift is the earliest warning signal. |
| 7 | How does it integrate with your ITSM platform? | Native connector with SAP context, not generic webhook. |
| 8 | What does the baseline setup process look like? | Weeks, not months. No SAP transports. |
| 9 | How does it handle hybrid and cloud landscapes? | BTP, RISE, NetWeaver, HANA in one view. |
| 10 | What reporting does it give to non-technical stakeholders? | Business process health, not raw metrics. |
| 11 | What happens when the monitoring system itself fails? | Self-monitoring and failover story. |
| 12 | How does pricing scale with your landscape? | Per SID. No hidden per-metric charges. |
How to use this checklist in practice ?
Run through these questions before the first vendor demo, not during it. If you send them to the vendor in advance, you will get prepared answers for the ones they have good answers to, and deflection or silence for the ones they do not. That itself is informative.
During the demo, ask for live demonstrations of the specific scenarios that matter to you. Not a general feature tour. Show me what happens when this job runs long. Show me the alert that fires when the HANA log volume crosses 70%. Show me what the ticket looks like in ServiceNow. Vendors who can demonstrate the specific scenario you describe are vendors who actually have the capability. Vendors who redirect to a future roadmap item or a custom configuration possibility are showing you the gap.
Run a proof of concept in your actual environment before making a final decision. Two to four weeks with your systems, your job profiles, and your alert configurations is worth more than twenty hours of demos. It will also reveal deployment complexity, baseline quality, and false positive rates that no demo environment will show you.
The evaluation process for a monitoring platform feels like overhead. It is not. The cost of choosing a tool that does not cover your actual landscape, that fires alerts nobody looks at, or that misses the silent failures that cause your most expensive incidents, is much higher than the time you spend asking these questions upfront.
Redpeaks covers SAP NetWeaver, S/4HANA, HANA, BusinessObjects, BTP, and cloud environments from a single agentless collector, with per-job duration baselines, spool-level alerting, and native ITSM integration.
