Skip to main content
Resilience Auditor — fails when the platform declared in the project’s software stack answers with its license activation page, which means its license has expired or the instance was never registered and visitors no longer reach the site.

Whole-site outage

When a Liferay DXP license expires, every page redirects to the activation page. The site is down for every visitor until a new key is deployed.

Silent until it happens

Nothing warns visitors or most monitors: the server keeps answering HTTP 200. Checking the activation page catches it on the first run after the key expires.
The auditor reads the software stack of the project, picks the platform a visitor supports and fetches one probe URL on the monitored site. The first supported platform is Liferay DXP; other platforms can be added as new visitors that reuse the same rules and codes.

​
How it works

  1. Select the platform — the first stack entry whose vendor is Liferay (any case) and whose product is not Liferay Portal is audited (Liferay Portal, the community edition, has no license). No stack, or no supported platform in it, is INFORMATION (100): nothing is fetched and the run is not charged.
  2. Fetch the probe URL — /c/portal/license_activation on the origin of the monitored URL, without following redirects, with 37AuditsBot’s user agent, its Web Bot Auth signature and the URL’s Basic Auth credentials. HTTP 403, HTTP 429 or a Cloudflare challenge is ERROR (590). A network error, a timeout or any status other than 200 or a redirect is ERROR (500).
  3. Read the answer
    • A redirect (Liferay sends 302 to /c/portal/layout) means the license is valid: SUCCESS (200).
    • 200 with the Liferay DXP Activation sheet (<h1 class="sheet-title">Liferay DXP Activation</h1>, rendered by license_activation.jsp) means the license is expired or the instance is not registered: FAIL (400). The alert on the page, such as This instance is not registered., is quoted in the message.
    • 200 with any other page is SUCCESS (200): the activation page is not served.

​
What it audits

Every row maps to one checkRule* method and one CheckCode. CheckCode suffixes use status ranges: 100 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error. Example messages:
  • 400 — "https://www.example.com/c/portal/license_activation" answered HTTP 200 with the Liferay DXP activation page ("This instance is not registered."): the Liferay DXP license is expired or the instance is not registered.
  • 200 — "https://www.example.com/c/portal/license_activation" answered HTTP 302 → "https://www.example.com/c/portal/layout", so the Liferay DXP license is active.
Findings carry the same values in data: platform, probeUrl, statusCode, location, pageTitle, activationPage and alert.

​
Output documentation

​
Risks and considerations

​
An expired license takes the whole site down

  • Liferay DXP redirects every page to the activation page once its license expires. Visitors, search engines and integrations all get that page instead of your content, so the impact is a full outage, not a degraded feature.

​
Check before it happens

  • Liferay license keys have a fixed end date. Run this auditor on a schedule so the first run after the key expires raises the alarm, and renew keys before their end date.
  • The activation page answers HTTP 200, so uptime monitors that only check the status code report the site as up.

​
The software stack is declared, not detected

  • Only projects whose stack lists Liferay DXP are audited. Add Liferay to the stack when the site runs on it.
  • Only the first Liferay entry of the stack is audited.

​
What this auditor does not check

  • It does not read the license’s end date, so it cannot warn ahead of the expiry.
  • It does not check the cluster-node or developer-connection limits beyond what the activation page reports.