How to keep your Liferay site online

Catch what expires, make the site fail cleanly, limit what can overload it, and be able to lose a server. Part three of the Liferay series.

Most Liferay outages are not dramatic. A certificate or a domain expires. A release goes out of support and the fix you need does not exist for it. A crawler asks the search page for ten thousand results at once. A node dies and it turns out the second one never had the same documents.

This journey goes through those in order: what expires without telling you, how the site behaves when something is missing or broken, what a visitor or a bot can do to overload it, and whether you can lose a server or restore from a backup.

After you register your Liferay version, steps 2 to 10 each have an auditor that checks your monitored URL. The last four are about your own infrastructure, taken from the fault tolerance guidance in Liferay's go-live checklist, and complete by hand.

Resilience is not a state you reach once. The last step sets these checks to run on a schedule, so the next expiry or regression reaches you before it reaches your visitors.

This is the third of three Liferay journeys. The others are How to secure your Liferay site and How to make your Liferay site fast.

Steps

Open a step to read it

1
Register your Liferay version
The End of Life and Latest Version auditors in steps 4 and 5 read the software stack of your project, not the site. Without a Liferay entry they have nothing to look up and report an error.
If you did this in the security journey, confirm the version is still right and mark the step complete.
Do this
- Open the project that owns this URL and find Software Stack
- Choose Add Software and set the vendor to Liferay
- Pick the product (DXP or Portal) and the version from the list the form offers. It is the list of releases Liferay publishes, so an installed release is always in it: 2025.Q1.16 LTS, 7.4 U101, 7.4.3.132 GA132
- Find the version under Control Panel → Server Administration, or in the startup log
Done when the project lists Liferay with the version that is running in production.
2
Keep the domain from expiring
Verifies with Domain Expiration Auditor
An expired domain takes down the site, the email and every integration that calls you by name, all at once, and it can take days to get back. It happens to large organisations because the renewal notice goes to someone who left.
The Domain Expiration Auditor reads the expiry date from the registry. More than 90 days passes, 31 to 90 is a warning, 30 or fewer fails.
Do this
- Turn on auto-renew at the registrar and check that the payment method on file is still valid
- Point the registrar account at a shared mailbox, not one person's address
- Turn on registrar lock so the domain cannot be transferred by mistake or by fraud
- Do the same for every domain your Liferay virtual hosts use
Done when the auditor passes. Some registries, such as .de and .ch, do not publish an expiry date. The auditor warns in that case and you mark the step complete yourself.
3
Keep the certificate from expiring
Verifies with Certificate Auditor
An expired certificate is an outage as far as visitors are concerned: browsers refuse the page, and API clients and mobile apps fail without showing anyone a warning.
The Certificate Auditor warns when the certificate has 30 days or fewer left and fails when it has expired or the chain is broken.
Do this
- Automate renewal where TLS ends, with ACME or your cloud provider's managed certificates
- If you renew by hand, put the date in a shared calendar with a reminder 30 days ahead
- In a cluster, check that every web server and load balancer got the new certificate. One node with the old one causes failures that come and go
- Cover every hostname your Liferay virtual hosts answer on
Done when the auditor passes with more than 30 days left.
4
Stay inside Liferay's support window
Verifies with End of Life Auditor
When a release line leaves support, fixes stop arriving for it, including security fixes. The longer you stay, the more releases you have to cross in one upgrade, and the upgrade becomes a project instead of a routine.
The End of Life auditor places the version in your Software Stack in Liferay's Service Life Policy. It fails when your line is past its end of life or within 180 days of it, and warns within a year of it or while the line is in Limited Support, where only critical security fixes ship. Both thresholds can be changed in its preferences on the URL's Configuration tab.
Do this
- Run the auditor and read the two dates it reports for your line: end of Premium Support and end of life
- If it fails, start the upgrade now. Pick a line with room: the Q1 release of each year is LTS, with three years of Premium Support and two of Limited Support
- If you are on a non-LTS quarterly line, know what you signed up for: one year of Premium Support and no Limited Support, so the auditor warns from the day the line ships. Either move to the next quarterly release as it comes out, or move to LTS
- Rehearse each update on a copy of production first
- After each update, change the version in the Software Stack
Done when the auditor passes: your line is in Premium Support with more than a year left. Liferay Portal, the community edition, has no published service life, so the auditor warns and you mark the step complete yourself once you are on its latest release.
5
Take fix releases as they come
Verifies with Latest Version Auditor
Staying on a supported line is half of it. The other half is running the latest fix release of that line, because that is where the bug fixes are, and because a fix Liferay builds for you lands on top of the current release of your line. Being several fix releases behind turns every support ticket into an update first.
The Latest Version auditor compares the version in your Software Stack with the release list Liferay publishes. It fails when a later fix release of your line exists, and warns when a newer line exists at all.
Do this
- Run the auditor. A failure names the fix release you should be on
- Apply it on a copy of production first, then in production. Fix releases stay inside the line and are the routine update you should be able to do without a project
- Put the next one in the calendar. Fix releases come out through the year
- After each update, change the version in the Software Stack and run again
Done when the auditor reports no later fix release of your line. The warning about a newer line belongs to the previous step. It stays while you are on an LTS line, so this step completes by hand.
6
Return a real 404
Verifies with Not Found Auditor
How a site answers for a page that does not exist says a lot about how it fails in general. A missing page that returns 200, or redirects to the home page, hides broken links from you and tells search engines the broken URL is real.
The Not Found Auditor requests an address that cannot exist. It fails when the answer is not a 404 or 410, or when the page does not say the content was not found. It warns when the page has no noindex, navigation, helpful links or search box.
Do this
- Keep layout.show.http.status=true so Liferay sends the 404 status
- Give the site a not-found page with your navigation, a link home and a search box. layout.friendly.url.page.not.found sets it for the portal and sites.friendly.url.page.not.found for sites. Check that the answer is still a 404 afterwards
- Check the web server too. An ErrorDocument or proxy rule that redirects errors to the home page turns every 404 into a 200
Done when the auditor passes. Its warnings keep this step from completing by itself. Fix the ones that help visitors and mark the step complete.
7
Keep the browser console clean
Verifies with Browser Console Messages Auditor
A JavaScript error is a part of the page that stopped working: a menu that does not open, a form that does not submit. Nobody reports these. Visitors leave.
The Browser Console Messages Auditor loads the page in a browser and fails for every error message in the console. Warnings in the console are warnings in the result.
Do this
- Run the auditor and read the messages
- On Liferay, look first at fragments and widget templates with inline scripts, client extensions that fail to load, third-party tags, and modules that are missing after an upgrade
- Fix or remove the source of each error
- Run it again after every deployment and every Liferay update. This check catches regressions more than anything else
Done when the console shows no errors on the monitored page.
8
Cap what search can return
Verifies with Search Auditor
A search page that returns every document for an empty query, or accepts any page size in the URL, lets one visitor or one crawler make Liferay and Elasticsearch build enormous responses. A few of those requests at once can stall the site.
The Search Auditor sends four requests to your search page: an empty query, a wildcard, and both again with a page size of 101. It counts the results and measures the time.
Before you run it
- On the URL's Configuration tab, set the Search auditor's resultSelector: the CSS selector or XPath of one result item, for example li.list-group-item. The auditor does not run without it
- If the monitored URL is not the search page, set searchPage, for example /search
Do this
- Turn off Allow Empty Searches on the Search Bar and Search Results widgets
- Limit the page size (delta) the Search Results widget accepts to 100 or less
- Reject wildcard-only queries such as * if you can
- Remove nested redirect parameters from pagination links. Each page adds the previous URL to the next and the links grow without limit
Done when the auditor passes. A wildcard query that returns results is a warning, not a failure, and keeps this step from completing by itself.
9
Slow down aggressive crawlers
Verifies with Robots Crawl Delay Auditor
Liferay renders pages on the server, so a crawler that requests thousands of URLs in a minute is real load, and faceted search and calendar pages give it an endless supply of URLs.
The Robots Crawl Delay Auditor reads /robots.txt. It fails when the file is missing, warns when it has no Crawl-delay, and passes when it has one.
Do this
- Edit the site's robots.txt in Liferay, in the site's settings. Each site with its own virtual host has its own file
- Add a Crawl-delay line, for example Crawl-delay: 10
- Disallow the paths that generate endless URLs, such as search results with facets
- Know the limit of this: well-behaved crawlers respect Crawl-delay, Googlebot ignores it, and abusive bots ignore the whole file. For those, add rate limiting at the web server, CDN or WAF
Done when the auditor finds a Crawl-delay in your robots.txt.
10
Prove the contact form delivers
Verifies with Contact Form
A contact form can show its thank-you message for months while the notification email goes nowhere, because the SMTP password changed or the recipient left. The only real test is to submit it and see the email arrive.
The Contact Form auditor does that. It fills in and submits your form, then waits for the notification to reach a 37 Audits inbox. Skip this step if the site has no form.
Before you run it
- On the URL's Configuration tab, set formPageUrl (the page with the form) and formSelector (the CSS selector of the form element)
- In the inbox that receives the form's notifications, add a rule that forwards them to contact-form-auditor@inbound.37audits.com
- For a Liferay form, check its settings first: email notifications must be on, with a recipient address
Know this
- Every run submits a real entry. It will appear in the form's records in Liferay, marked as a 37 Audits probe
- The result stays pending until the email arrives, up to 15 minutes by default
Done when the auditor reports that the notification arrived. If the form accepted the entry and no email came, check Liferay's mail server settings and the mail log.
11
Run two nodes in every tier
From here on, the steps are about your own infrastructure and nothing outside can check them. Liferay's reference architecture has at least two servers in each tier: web, Liferay, search and database. The goal it states is to meet your service level at peak load after losing a server in any tier.
Do this
- Run at least two Liferay nodes behind a load balancer with health checks, so a dead node stops receiving traffic
- Set cluster.link.enabled=true on every node. Without it, each node keeps its own caches and they drift apart
- Point every node at the same database and the same Documents and Media store. With the file system store that means shared storage. Liferay recommends the Advanced File System Store on premises, or an object store such as S3
- Decide what happens to sessions when a node dies: sticky sessions with a new sign-in, or session replication
- Make the database highly available with your vendor's replication and failover
- Size each tier so that the remaining nodes carry the peak when one is gone
Done when you have stopped one Liferay node under load and the site kept answering.
12
Run Elasticsearch as a cluster
If Elasticsearch is down, Liferay is mostly down: search, content listings and parts of the Control Panel all depend on it.
Do this
- Run a standalone Elasticsearch cluster. The sidecar that ships with Liferay is for development only
- Use at least three master-eligible nodes, so the cluster keeps a quorum when one fails
- Keep the cluster inside one region. Do not stretch one cluster across data centres far apart. Use cross-cluster replication for that
- Set the disk watermarks, so the cluster stops allocating to a node before its disk is full
- Set action.destructive_requires_name: true, so nobody deletes every index with a wildcard
- Monitor the cluster with Kibana or Metricbeat
Done when you have stopped one Elasticsearch node and search kept working.
13
Back up and rehearse a restore
A Liferay site is three sets of data that have to match: the database, the Documents and Media store, and the search index. Liferay does not back up any of them for you. Its checklist says so directly about the file store.
Do this
- Back up the database on a schedule that matches how much work you can afford to lose
- Back up the Documents and Media store at the same point in time. A database restored without its files leaves documents that open as errors
- Take Elasticsearch snapshots and automate them with snapshot lifecycle management. The index can be rebuilt by reindexing, but on a large site that takes hours with search degraded
- Keep portal-ext.properties, the OSGi configuration files and your deployed modules in version control
- Store copies away from the servers they protect
- Restore everything into an empty environment and start Liferay on it. Time it
Done when you have completed a full restore and know how long it takes. A backup that has never been restored is not yet a backup.
14
Keep watching
Everything in this journey can pass today and fail next month: a certificate renews late, an update brings a script error, someone turns empty searches back on. Checks that run by themselves tell you first.
Do this
- On the URL's Configuration tab, switch on scheduled monitoring for the auditors from this journey and choose an interval. Once a day is enough for all of them. Scheduling needs a plan that includes scheduled monitoring
- Think before scheduling the Contact Form auditor: every run submits a real entry to your form
- Do the same for your search page and your form page if they are separate URLs
- Add -XX:+HeapDumpOnOutOfMemoryError to the JVM, so an out-of-memory crash leaves something to analyse
- Set alerts in your monitoring tool for heap use, thread pool saturation, database connection waits and Elasticsearch cluster health
- Write down who is called when an alert fires, and what they do first
Done when the schedules are on and an alert reaches a person.
Two things from the rest of the series also keep the site up. Cache and CDN, in How to make your Liferay site fast, take traffic off the origin during a spike. Patching, in How to secure your Liferay site, closes the holes that become incidents.

Create an account, add your site as a monitored URL and work through these steps on it.