You can’t get those exact Service Center “Environment Health” values (Front-end Server services and Cache Invalidation Service status) directly in your apps, because OutSystems doesn’t expose them via public APIs or system entities.

Below is what is and isn’t possible, and some practical alternatives.

1. Where can I find these values?

Those values (per‑service status on each Front-end, Cache Invalidation Service status, etc.) are internal to the platform and are only exposed in:

• Service Center → Monitoring → Environment Health → Front-End Servers
• Service Center → Monitoring → Environment Health → Cache Invalidation Service

There is no public OutSystems API that returns:

• The per‑FE “Deployment Controller / Scheduler / Log Service / Deployment Service” status,
• Or Cache Invalidation Service status,
  for you to consume in your own modules. Environment monitoring

The LifeTime SDK only exposes generic environment information (e.g., number of front‑ends), not their detailed health or service status. About FE Dead or Alive monitoring

2. How can I get any of these values to use in my screens?

You can’t call a built‑in OutSystems API that returns the same data as the “Front-end servers” grid or “Cache Invalidation Service” status.

What is available:

• System Entities / Logs / Processes
  As you already noticed, the “Processes” numbers visible in Environment Health can be retrieved from System Entities (e.g., process instances, emails, timers) and logs. You can use those to show counts or trends in your own dashboards. Environment monitoring

• Lifetime API – EnvironmentInfo
  You can call LifeTime APIs to list environments and see how many front-ends exist, but not their health status. About FE Dead or Alive monitoring

Beyond that, there’s no native API for:

• “Is this FE service green/red?”
• “Is cache invalidation service up?”

So you can’t reproduce that exact table via supported APIs.

3. Alternatives to analyze/show status in your app

Since the platform doesn’t expose the same environment health data, the usual approach is to implement availability checks at application or infrastructure level, and show those results in your screen.

Here are common patterns:

A. Application-level health checks

Create a simple “health” or “ping” REST endpoint in each app/API and call it from your monitoring logic:

1. In each module/app:

   • Expose a REST GET /health or /ping that:
     • Reads from DB (simple query),
     • Calls some critical dependencies (if needed),
     • Returns 200 OK and maybe a JSON like { "status": "OK", "app": "MyApp" }.

2. In your monitoring module:

   • Use Timers or Server Actions to:
     • Call those endpoints periodically,
     • Store response time and HTTP status in a log entity.
   • In your screen:
     • Show status per app based on last check (OK / Degraded / Down).

This is very similar to the approach recommended by OutSystems for “detecting OutSystems server and app availability” in load balancing setups. About FE Dead or Alive monitoring

B. Infrastructure-level monitoring

As suggested in the forum:

“we did everything on infrastructure level … Call URL from the APP/API's etc, if there is no answer or bad http code you know the status.” App or Environment uptime / downtime / status

You can use:

• Load balancer health checks (hitting an OutSystems app URL),
• External tools (Nagios, Zabbix, Prometheus, StatusPage, etc.)
  to:
• Ping your OutSystems web/API URLs,
• Check specific ports/services on each FE server,
• Then feed that into a “status page”.

You can then consume those external metrics via REST in your OutSystems app if desired.

C. Use platform logs / timers / processes as indicators

You can approximate environment health by:

• Monitoring:
  • Error logs count,
  • Slow or failing timers (long runtimes, many queued instances),
  • Large queued process or email counts.
• Displaying those aggregates with simple thresholds:
  • Example: “Timer X has N queued instances” or “Error log count in last 5 minutes > threshold → show warning”.

This won’t tell you “Cache Invalidation Service is down”, but it gives a practical view of platform health.

Summary

1. Exact Service Center FE/Cache status values are not available via APIs or system entities for use in your screens.
2. You can show related health information using:
   • System entities (processes, emails, timers, logs),
   • Lifetime API (environment & FE count, not health),
   • Custom health endpoints and timers that check URL availability.
3. For a “status page”:
   • Implement health-check endpoints per app/API,
   • Or rely on infrastructure tools that ping your OutSystems URLs,
   • Then use those results to show status (Up/Down/Degraded) instead of trying to replicate the internal Service Center tables.