2am, the pager, the PDF
The scenario I built this for is boring and specific. It is Sunday, 2am. A tenant HANA system misbehaves and the on-call engineer gets paged. Somewhere in the ticket there is a link to an EarlyWatch report. That report is a PDF. It is about forty pages. It has a summary at the top with red, yellow, and green squares, then twenty or so sections that dig into memory, disk, log growth, backup status, patch level, savepoint duration, expensive statements, security anomalies, and a long tail of items that only bite once a year.
An experienced engineer knows which pages actually matter at 2am. Page one for the summary. Skip the front matter. Jump to memory, then to disk, then to backup, then to alerts. The rest can wait for the morning. That knowledge is not written down anywhere I could find. It lives in the heads of the two or three colleagues who have done this a hundred times, and I am not one of them.
I wanted a screen that captured that instinct so I did not have to grow it the hard way.
Before I go further: the repo is private and the EarlyWatch content itself is customer data. I cannot show screenshots or paste real values. What I can share is the shape of the tool, the technical choices, and the tradeoffs. The specific check thresholds and the field names in the report are SAP internal. I will describe what the dashboard surfaces at the category level (memory, backup, patches, security) without quoting the report.
What SAP HANA EarlyWatch is, briefly
For readers outside the SAP world: EarlyWatch is a proactive health check that SAP generates on a schedule for HANA systems that subscribe to the service. It reads a large set of metrics from the system, compares them against baselines that SAP has learned from thousands of installations, and produces a report. The report calls out anomalies (memory usage climbing week over week, log volume growing faster than expected, a savepoint that is taking longer than it should, a patch level that is behind), security concerns (default users still enabled, weak audit trail settings), and operational risk items (backup age, disk headroom, trace file volume).
The report has three kinds of readers. A Basis administrator scans it to catch problems before they escalate. An on-call engineer opens it because a specific alert already fired. A customer executive skims the top page to confirm the system is healthy. Same PDF, three very different reading patterns.
What the dashboard actually surfaces
I built for the on-call engineer. That reader wants three things fast:
Top of screen, the two or three numbers that decide whether this is a real incident or a stale page. Free memory headroom, log volume trend, last successful backup age. If any of those is red, the dashboard makes it big and pushes everything else down.
Middle of screen, the deltas. Not the absolute value of a metric, but how it has moved since the last report. A HANA system that has always had 60 percent memory used is fine. A system that jumped from 45 to 60 in one week is a story. The report contains both current and historical values in most sections. The dashboard subtracts them and colours the delta.
Bottom of screen, drill-through. Clicking a KPI opens the PDF on the exact page that check came from. This is the part that took the longest to get right and is the part I like the most. The engineer trusts the number more when they can see the raw table it was pulled from, on the page it was pulled from, without hunting for it. I use pdf.js to render the report in the right pane and scroll it programmatically when a KPI is clicked.
Below the KPIs is a recommendations panel. If a check comes back yellow or red, the dashboard suggests the next SQL query or hdbsql command to run. If the engineer approves, an agent panel can execute it against the target system through a small HTTP daemon on the box, the same shape as the HaaS agent I wrote about earlier. The commands are pre-vetted, read-only by default, and every execution goes into a log the engineer can review before they close the ticket.
The tech
React 18 with Vite, and that is most of the story. There is no framework, no server-side rendering, no state library. The app is a single React tree with useState and useCallback at the top of App.jsx, and every panel below reads from those hooks. When the tree got too wide I split into panels (top bar, PDF viewer, analysis, recommendations, agents), not into stores.
PDF parsing runs in the browser. I use pdf.js to pull text out of each page, then a small handwritten parser walks the text looking for the section headings EarlyWatch uses. The parser is not clever. It matches known section titles and known table shapes, then extracts the numbers by regex. This is fragile against SAP changing the report format, and it will break the next time they do. I accepted that tradeoff because a browser-side parser meant I never had to send customer data to a server I did not control.
Analysis is a mix of local heuristics and a call to SAP AI Core. The heuristic path handles the checks I know how to write rules for (memory delta, backup age, patch drift). The AI Core path handles the free-form recommendation text at the end of each section, where the report suggests a fix in plain English and I want a short summary next to it. Both paths write into the same analysis object that the panels read from.
The agent execution talks to a FastAPI daemon on the HANA VM over an X-API-Key header. I wrote a whole post about why that design makes me nervous. The short version is that it works, the key sits in .env, and I only enable execution for a small set of read commands. Anything that could write goes through a manual confirm.
What a dashboard like this trades off
Density versus clarity. The PDF has, at a guess, three hundred distinct metrics. I show maybe fifteen on the top screen. Everything else is either one click away or hidden until the engineer asks. I lost some readers who wanted the full grid at once. I kept the on-call reader I built for.
Historical versus current. The report ships with a week of history for most metrics and a longer window for some. I chose to show one number and one delta, not a sparkline. Sparklines look great and they slow down the read. A red arrow next to a number is faster.
Expert versus generalist. My colleague who has done this a hundred times does not need the dashboard. He opens the PDF, ctrl-F for "backup", reads the row, closes the PDF. The dashboard is slower for him. It is much faster for me, and for the version of me that will be on-call in six months and will have forgotten which page mattered. The right test for a tool like this is not whether the expert prefers it, it is whether the person on their third on-call shift can finish the triage without paging the expert.
The thing I would build next, if I picked this up again, is a compare view: this week's report next to last week's, deltas of deltas. That is where the interesting anomalies hide, and it is the one view the current dashboard does not have.