Individual health checks reference

This page contains detailed information about individual health checks. Categories match the Health App pages you see in the Cockpit: performance, deployment, security, domains, and miscellaneous checks.

For in-app help while you work, expand What is this? on any check card. The entries below are sourced from the same embedded glossary used in Cockpit.

Performance checks

CDN checks

How often your website is actually working for visitors

This checks if your website is up and running properly. We look at how many visitors got error messages (like “Service Unavailable”) versus how many could access your site normally in the past hour.

What we’re measuring: Percentage of successful visits
Target: At least 99.8% uptime
Why it matters: If this drops, it means visitors can’t reach your website

What you can do: Check your DX Cloud instance status and deployment logs. If issues persist, scale up your instance resources or contact Magnolia support. Review recent deployments that might have introduced instability.

How fast visitors can connect to your website

This measures the time it takes for a visitor’s browser to send a request to your server and get a response back - like measuring how long it takes to knock on a door and hear “come in.”

What we’re measuring: Average connection time
Target: Under 200 milliseconds
Why it matters: Slower connections frustrate visitors and hurt your search rankings

What you can do: Verify your CDN configuration is properly distributing traffic to edge locations. Check if your DX Cloud region is optimal for your audience. Consider enabling additional CDN endpoints closer to your users.

How long it typically takes your pages to load

This tracks how long your server takes to process requests and send back web pages. Think of it as how long visitors wait after clicking a link before seeing your content.

What we’re measuring: Average time to load pages
Target: Under 1 second
Why it matters: Slow pages cause visitors to leave and hurt conversions

What you can do: Optimize your Magnolia templates and components for performance. Review database queries in your custom modules. Enable Magnolia’s built-in caching mechanisms and consider upgrading your DX Cloud instance tier.

How long your slowest pages take to load

While most of your pages might load quickly, this catches the slowest 5% that could be frustrating some visitors. It’s like finding the longest wait times at your busiest moments.

What we’re measuring: 95% of pages load within this time
Target: Under 1 second even for the slowest pages
Why it matters: Even if most pages are fast, slow pages hurt user experience

What you can do: Identify heavy pages using Magnolia’s performance monitoring. Optimize complex templates, reduce component nesting, and implement lazy loading for images and content blocks. Review any custom integrations that might be slow.

How often your website breaks or crashes

This counts server errors (like crashes or database failures) that prevent visitors from seeing your content. It’s like tracking how often your store is closed when customers try to visit.

What we’re measuring: Percentage of visits that hit server errors
Target: Less than 1% of visits
Why it matters: High error rates mean lost customers and damaged reputation

What you can do: Check Magnolia’s error logs and application monitoring. Review recent content changes or module deployments. Ensure your DX Cloud instance has adequate memory and CPU resources. Test integrations with external systems.

How often things go wrong for visitors

This includes both server problems and user errors (like broken links or missing pages). It gives you the full picture of how many visitors encounter problems.

What we’re measuring: Percentage of all failed requests
Target: Less than 2% of all requests
Why it matters: Any errors hurt user experience and your site’s credibility

What you can do: Audit your content for broken internal links using Magnolia’s link checker. Review URL patterns and redirects. Check that all assets (images, CSS, JS) are properly published and accessible. Fix any 404 errors from outdated content.

How well your speed optimization is working

When visitors request the same content, a good website serves it from a fast cache instead of recreating it each time. This measures how often we can serve that cached content.

What we’re measuring: Percentage of requests served from cache
Target: At least 80% from cache
Why it matters: Better caching means faster loading and lower server costs

What you can do: Configure appropriate cache headers in your Magnolia templates. Enable page caching for static content. Review your cache invalidation strategy; ensure content updates properly clear relevant caches. Consider implementing Magnolia’s REST delivery for better caching.

How much of your content can be cached for speed

This shows what percentage of your website traffic could potentially be served from cache to make it faster. Higher coverage means more opportunities for speed improvements.

What we’re measuring: Percentage of requests that could use caching
Target: At least 50% of traffic
Why it matters: More cacheable content means better performance potential

What you can do: Review your site architecture to identify dynamic content that could be made cacheable. Implement Magnolia’s fragment caching for partially dynamic pages. Separate user-specific content from cacheable page elements. Consider using Magnolia’s REST delivery layer for better cache coverage.

Ingress checks

How often your core application is reachable

This monitors whether your Magnolia DX Cloud instance is responding to requests at the ingress level, before CDN processing. It’s like checking if your server is answering the phone when called directly.

What we’re measuring: Percentage of successful direct connections to your instance
Target: At least 99.8% uptime
Why it matters: If this fails, your entire website goes down regardless of CDN status

What you can do: Check your DX Cloud instance health in the management console. Verify your Kubernetes ingress configuration is correct. Review pod status and restart unhealthy containers. Scale your instance if resource limits are being hit.

How quickly your server infrastructure responds

This measures the direct connection time to your Magnolia instance, bypassing CDN. It shows the raw performance of your DX Cloud infrastructure and network connectivity.

What we’re measuring: Direct connection time to your instance
Target: Under 200 milliseconds
Why it matters: High ingress latency affects all subsequent processing and user experience

What you can do: Check your DX Cloud region selection, ensure it’s geographically close to your users. Review network configuration and firewall rules. Consider upgrading your instance size for better network performance. Monitor for network congestion during peak times.

How long your Magnolia instance takes to process requests

This tracks the time your DX Cloud instance needs to generate responses, measured at the ingress before any caching or CDN optimization.

What we’re measuring: Average processing time at the instance level
Target: Under 1 second
Why it matters: Slow ingress response times compound with CDN latency and affect overall performance

What you can do: Profile your Magnolia application performance using JVM monitoring tools. Optimize database queries and review slow-performing templates. Check Java heap and garbage collection settings. Consider increasing CPU/memory allocation for your DX Cloud instance.

How long your slowest server requests take

This captures the longest response times from your Magnolia instance, helping identify performance bottlenecks that affect a minority of requests but could be critical.

What we’re measuring: 95% of requests complete within this time at instance level
Target: Under 1 second even for complex requests
Why it matters: Slow tail requests often indicate resource contention or inefficient code paths

What you can do: Identify specific pages or operations causing slow responses using Magnolia’s request logging. Review complex content queries and template logic. Implement connection pooling for external integrations. Monitor JVM performance during peak loads and tune garbage collection.

How often your Magnolia application encounters internal errors

This tracks server-side errors (5XX) originating from your DX Cloud instance, indicating problems with your Magnolia application, database, or infrastructure.

What we’re measuring: Percentage of requests resulting in server errors at instance level
Target: Less than 1% of requests
Why it matters: High service error rates indicate application instability or infrastructure problems

What you can do: Review Magnolia application logs and error traces in DX Cloud console. Check database connectivity and performance. Verify all required modules are properly installed and configured. Monitor memory usage and restart instances showing memory leaks.

How often requests fail at your server level

This includes both client errors (4XX) and server errors (5XX) at the ingress level, giving you the complete picture of failed requests before CDN processing.

What we’re measuring: Percentage of all failed requests at instance level
Target: Less than 2% of all requests
Why it matters: High error rates at ingress level indicate fundamental application or configuration issues

What you can do: Analyze request patterns to identify problematic URLs or user agents. Review Magnolia’s URL mapping and virtual URI configuration. Check for missing resources or broken internal links. Validate security configurations aren’t blocking legitimate requests. Update sitemap and fix any structural navigation issues.

Magnolia checks

How often your public website is responding to requests

This checks whether your Magnolia public instance is successfully handling incoming requests. We compare successful responses against failed ones to show how reliably your live site is serving visitors.

What we’re measuring: Percentage of successful requests handled by your public Magnolia instance
Target: At least 99.0%
Why it matters: Low availability means visitors cannot access your website, even when CDN and ingress layers are healthy

What you can do: Review Magnolia application logs and recent deployments on your public instance. Check database connectivity and pod health in your environment. Restart unhealthy public pods if needed and contact support if availability remains low.

How often your public website logs errors

This tracks how many ERROR log entries are produced per second by your public Magnolia instance. A rising error log rate often signals application faults, integration failures, or configuration problems affecting visitors.

What we’re measuring: Error log rate (req/s) on the public instance
Target: 0.0 req/s
Why it matters: High error rates indicate recurring problems that can degrade site reliability and visitor experience

What you can do: Open Magnolia application logs and filter for ERROR entries on your public instance. Identify the most frequent error classes and correlate spikes with recent deployments or traffic changes. Fix underlying integration, template, or configuration issues before they affect availability.

How long your public website typically takes to respond

This measures the average time your Magnolia public instance needs to process requests and return responses. It reflects typical page and API performance as experienced before CDN edge caching.

What we’re measuring: Average response time for requests handled by the public instance
Target: At most 1000 ms
Why it matters: Slow average response times make pages feel sluggish and hurt conversions and search rankings

What you can do: Profile slow templates and database queries in your public Magnolia instance. Review caching configuration and enable Magnolia page or fragment caching where appropriate. Consider scaling CPU or memory if response times stay high during normal traffic.

How long your slowest public requests take

While most requests may be fast, this captures the slowest 5% of responses from your public Magnolia instance. These tail latencies often reveal bottlenecks that affect a subset of pages or operations.

What we’re measuring: 95th percentile response time for the public instance
Target: At most 1000 ms
Why it matters: Slow tail requests frustrate visitors on heavy pages and indicate resource contention or inefficient code paths

What you can do: Use Magnolia request logging to identify URLs or operations with the longest response times. Optimize complex templates, reduce component nesting, and review external integrations on slow paths. Monitor JVM and database performance during peak traffic periods.

How much debug logging your public website produces

This tracks how many DEBUG log entries are produced per second by your public Magnolia instance. Excessive debug log rate can increase log volume, storage costs, and noise when troubleshooting real issues.

What we’re measuring: Debug log rate (req/s) on the public instance
Target: 0.0 req/s
Why it matters: High debug volume makes it harder to spot errors and warnings and may indicate overly verbose logger configuration in production

What you can do: Review logger levels for your public instance in Environments > Loggers. Reset custom DEBUG loggers to INFO or WARN after troubleshooting. Avoid leaving verbose package-level loggers enabled on production public instances.

How much time passes between errors on your public website

Mean Time Between Errors (MTBE) shows the average interval between consecutive ERROR log entries on your public Magnolia instance. Shorter intervals mean errors are occurring more frequently.

What we’re measuring: Average time between ERROR log entries on the public instance
Target: At least 10 ms
Why it matters: A declining MTBE suggests accelerating or recurring failures that can precede broader outages

What you can do: Correlate MTBE drops with deployments, traffic spikes, or configuration changes. Inspect error logs around the times when MTBE shortened to find the root cause. Address recurring error classes before they impact availability or response times.

How often your author environment is responding to requests

This checks whether your Magnolia author instance is successfully handling incoming requests from content editors and system processes. We compare successful responses against failed ones to show how reliably your editing environment is available.

What we’re measuring: Percentage of successful requests handled by your author Magnolia instance
Target: At least 99.0%
Why it matters: Low author availability blocks content editing, publishing workflows, and administrative tasks

What you can do: Review Magnolia application logs and pod status for your author instance. Check database connectivity and recent deployments that may have affected the author environment. Restart unhealthy author pods if needed and contact support if availability remains low.

How much debug logging your author environment produces

This tracks how many DEBUG log entries are produced per second by your Magnolia author instance. High debug log rate is common during troubleshooting but should not persist in normal operation.

What we’re measuring: Debug log rate (req/s) on the author instance
Target: 0.0 req/s
Why it matters: Excessive debug logging obscures errors and warnings and may indicate loggers left at verbose levels after investigation

What you can do: Review logger levels for your author instance in Environments > Loggers. Reset custom DEBUG loggers to INFO or WARN once troubleshooting is complete. Scope verbose loggers to specific packages rather than enabling broad DEBUG logging platform-wide.

How often your author environment logs errors

This tracks how many ERROR log entries are produced per second by your Magnolia author instance. A rising error log rate can disrupt content editing, publishing, and administrative operations.

What we’re measuring: Error log rate (req/s) on the author instance
Target: 0.0 req/s
Why it matters: High error rates on author indicate faults that can block editors and delay content workflows

What you can do: Open Magnolia application logs and filter for ERROR entries on your author instance. Identify frequent error classes and correlate spikes with recent module deployments or configuration changes. Resolve integration, indexing, or repository issues before they affect publishing.

How long your author environment typically takes to respond

This measures the average time your Magnolia author instance needs to process requests such as page loads, saves, and admin operations. It reflects typical responsiveness for content editors during day-to-day work.

What we’re measuring: Average response time for requests handled by the author instance
Target: At most 1000 ms
Why it matters: Slow average response times cause laggy editing, delayed saves, and frustrated content teams

What you can do: Profile slow admin operations and templates on your author instance. Review database and JCR query performance during content editing workflows. Consider scaling author resources if response times stay high with normal editor activity.

How much time passes between errors in your author environment

Mean Time Between Errors (MTBE) shows the average interval between consecutive ERROR log entries on your Magnolia author instance. Shorter intervals indicate errors are occurring more frequently and may disrupt editing workflows.

What we’re measuring: Average time between ERROR log entries on the author instance
Target: At least 10 ms
Why it matters: A declining MTBE on author often precedes failed saves, publishing issues, or admin interface instability

What you can do: Correlate MTBE drops with deployments, bulk imports, or module updates on author. Inspect error logs when MTBE shortens to identify recurring failure patterns. Fix root causes before they block content teams or publishing pipelines.

How long your slowest author requests take

While most author operations may be fast, this captures the slowest 5% of responses from your Magnolia author instance. These tail latencies often affect heavy editing tasks, large asset uploads, or complex admin operations.

What we’re measuring: 95th percentile response time for the author instance
Target: At most 1000 ms
Why it matters: Slow tail requests cause noticeable delays during critical editing and publishing activities

What you can do: Identify slow operations using Magnolia request logging on your author instance. Optimize heavy templates, bulk operations, and indexing tasks that drive long response times. Monitor JVM and database performance during peak editing periods.

Deployment checks

Platform checks

Whether your cluster nodes are running without memory pressure

This checks Kubernetes node conditions for memory-pressure taints. If a node is under memory pressure, workloads may be evicted or become unstable.

What we’re measuring: Number of healthy nodes (without memory-pressure taints) compared to total nodes in the cluster
Target: All nodes healthy (no memory-pressure taints)
Why it matters: Memory pressure on nodes can cause pod evictions, degraded performance, and workload instability

What you can do: Review node memory usage and identify pods with unusually high memory consumption. Scale node capacity or rebalance workloads if pressure persists. Investigate recent deployments that increased memory demand.

Whether your cluster nodes are running without disk pressure

This checks Kubernetes node conditions for disk-pressure taints. Disk pressure indicates nodes are running low on storage for runtime operations.

What we’re measuring: Number of healthy nodes (without disk-pressure taints) compared to total nodes in the cluster
Target: All nodes healthy (no disk-pressure taints)
Why it matters: Disk pressure can block scheduling, cause pod failures, and disrupt logging or container runtime operations

What you can do: Inspect node disk usage and clean up unnecessary images, logs, or temporary files. Review workloads generating large local storage volumes. Increase node storage capacity if pressure is recurrent.

Whether your cluster nodes are running without process pressure

This checks Kubernetes node conditions for pid-pressure taints. Process pressure means nodes are nearing process ID limits.

What we’re measuring: Number of healthy nodes (without process-pressure taints) compared to total nodes in the cluster
Target: All nodes healthy (no process-pressure taints)
Why it matters: Process pressure can prevent new processes from starting and cause service instability

What you can do: Review workloads with unusually high process/thread counts. Investigate runaway processes or crash loops creating excess processes. Scale or rebalance workloads if nodes frequently approach PID limits.

Whether your cluster nodes are ready to run workloads

This checks Kubernetes node conditions for not-ready taints. A not-ready node cannot reliably host workloads.

What we’re measuring: Number of ready nodes (without not-ready taints) compared to total nodes in the cluster
Target: All nodes ready
Why it matters: Not-ready nodes reduce platform capacity and can affect workload availability and resilience

What you can do: Inspect node condition events and kubelet status for affected nodes. Check network, resource, and runtime health on the node. Replace or recover unhealthy nodes before capacity is impacted.

Whether your cluster nodes are reachable by the control plane

This checks Kubernetes node conditions for unreachable taints. Unreachable nodes are not communicating properly with the cluster control plane.

What we’re measuring: Number of reachable nodes (without unreachable taints) compared to total nodes in the cluster
Target: All nodes reachable
Why it matters: Unreachable nodes can lead to service disruption, delayed failover, and incomplete cluster state

What you can do: Verify network connectivity between nodes and control plane endpoints. Check node runtime and kubelet health for communication failures. Escalate persistent reachability issues to platform support.

Whether your cluster nodes can accept new workloads

This checks node schedulability flags and taints to confirm nodes are available for scheduling. Unschedulable nodes reduce effective cluster capacity.

What we’re measuring: Number of schedulable nodes compared to total nodes in the cluster
Target: All nodes schedulable
Why it matters: Reduced schedulable capacity can cause pending pods, slower recoveries, and deployment delays

What you can do: Review why nodes were marked unschedulable (maintenance, taints, or incidents). Uncordon nodes once maintenance is complete and health is restored. Plan capacity to tolerate temporary unschedulable nodes.

Whether any cluster nodes have been cordoned

This checks for the unschedulable taint indicating nodes were cordoned and prevented from receiving new pods. Cordoned nodes are often intentional during maintenance, but should be temporary.

What we’re measuring: Number of uncordoned nodes compared to total nodes in the cluster
Target: No unexpected cordoned nodes
Why it matters: Long-lived cordoned nodes reduce available capacity and can affect resilience during failures

What you can do: Confirm whether cordoned nodes are part of planned maintenance. Uncordon nodes when maintenance is complete and node health is verified. Investigate and resolve underlying reasons for unplanned cordons.

Instance and deployment checks

Magnolia instance, database, redirect, and platform configuration checks reported under Deployments in the Health App.

How stable your content editing environment performs

This ensures your author instance has consistent CPU performance so content editors don’t experience slowdowns or lag when creating and managing content.

What we’re measuring: CPU resource allocation stability for content management
Target: Consistent performance without spikes
Why it matters: Unstable CPU causes frustrating delays during content editing

What you can do: Monitor content editing patterns for resource-heavy operations. Contact support for CPU optimization if you see consistent performance issues. Consider upgrading your DX Cloud plan if you have many simultaneous editors.

Whether your admin interface loads correctly

This checks if your Magnolia author interface is accessible at the correct URL path without conflicts that could prevent editors from logging in or accessing features.

What we’re measuring: Proper URL configuration for author access
Target: Clean, accessible author interface URL
Why it matters: URL conflicts prevent content editors from working effectively

What you can do: Verify your author URL configuration in DX Cloud settings. Check for custom URL mappings that might conflict. Contact support if you can’t access the author interface through standard paths.

How much memory your content management system uses

This tracks memory consumption in your author instance to ensure smooth content editing, fast asset uploads, and responsive page creation workflows.

What we’re measuring: Memory usage for content management operations
Target: Adequate memory for editing activities
Why it matters: Low memory causes slow editing, failed uploads, and system freezes

What you can do: Monitor memory during large asset uploads or bulk content operations. Optimize large files before uploading. Break up large content imports into smaller batches. Contact support for memory upgrades if issues persist.

How reliably your editing environment performs

This prevents unexpected memory limitations that could cause the author interface to become slow or unresponsive during critical content editing tasks.

What we’re measuring: Stable memory allocation for content editing
Target: Consistent memory availability
Why it matters: Memory inconsistency disrupts content workflows and productivity

What you can do: Report any sudden performance drops to support. Monitor for memory-intensive custom modules or integrations. Consider staggering content editing activities during peak usage times.

How efficiently your editing system components communicate

This ensures optimal placement of your author instance and database for fast content saving, quick admin interface loading, and responsive content operations.

What we’re measuring: Optimal service positioning for content management
Target: Fast communication between author components
Why it matters: Poor deployment causes delays in content saving and loading

What you can do: Report slow admin interface performance to support. Monitor content saving times and page loading in the author environment. Support can optimize deployment configuration for better performance.

How your system memory handles background operations

This monitors specialized memory used for content indexing, search functionality, and system operations that keep your author interface running smoothly.

What we’re measuring: System memory usage beyond content storage
Target: Stable background operation memory
Why it matters: Issues cause search problems and system instability

What you can do: Monitor search functionality and content indexing performance. Check if custom modules are consuming excessive system memory. Contact support immediately if you notice system instability.

Whether you have access to the latest platform features

This checks if you’re using a current version of Magnolia DX Cloud, ensuring access to new features, security improvements, and performance optimizations.

What we’re measuring: Currency of your cloud platform version
Target: Recent platform version
Why it matters: Outdated versions miss security updates and performance improvements

What you can do: Review release notes for new features available in latest versions. Schedule platform updates with support during low-traffic periods. Plan testing for any custom integrations before updating.

Whether your environment setup follows best practices

This validates that your environment naming clearly distinguishes between development, staging, and production to prevent accidental changes to the wrong environment.

What we’re measuring: Clear, appropriate environment identification
Target: Descriptive, unambiguous environment names
Why it matters: Poor naming leads to costly mistakes on wrong environments

What you can do: Review your environment naming convention with your team. Ensure names clearly indicate purpose (dev, staging, prod).

Whether your deployment uses supported infrastructure

This verifies your Magnolia instance uses tested, supported deployment methods that guarantee compatibility with updates and maintenance procedures.

What we’re measuring: Use of supported deployment infrastructure
Target: Approved deployment configuration
Why it matters: Unsupported configurations cause update failures and instability

What you can do: Work with support to validate your deployment configuration. Avoid custom infrastructure modifications that aren’t supported. Plan migrations to supported configurations if needed.

Whether your deployment infrastructure is current

This ensures your deployment tools are up-to-date for better stability, security, and compatibility with Magnolia updates and new features.

What we’re measuring: Currency of deployment infrastructure tools
Target: Recent, supported infrastructure version
Why it matters: Outdated infrastructure causes deployment failures and security risks

What you can do: Schedule infrastructure updates during maintenance windows. Contact support to plan upgrades that won’t disrupt your content operations. Test deployment processes after infrastructure updates.

Whether Magnolia has the latest features and security

This monitors your Magnolia version to ensure you have access to new content management features, performance improvements, and security enhancements.

What we’re measuring: Version of your Magnolia installation
Target: Recent Magnolia version with latest features
Why it matters: Outdated versions lack security patches and useful features

What you can do: Review Magnolia release notes for new features and improvements. Test custom modules for compatibility before upgrading. Plan updates during content freeze periods to avoid disruption.

How consistently your website performs for visitors

This ensures your public website maintains stable CPU performance so visitors experience consistent page loading speeds without sudden slowdowns.

What we’re measuring: CPU performance consistency for website visitors
Target: Stable performance during traffic variations
Why it matters: CPU inconsistency causes unpredictable visitor experience

What you can do: Monitor website performance during traffic spikes. Identify resource-intensive pages or features causing CPU peaks. Consider upgrading your DX Cloud plan for high-traffic sites.

How efficiently your website handles visitor traffic

This tracks memory usage for your public website to ensure fast page loading and reliable handling of traffic spikes without performance degradation.

What we’re measuring: Memory usage for public website operations
Target: Adequate memory for expected traffic levels
Why it matters: Memory issues cause slow loading and potential site outages

What you can do: Monitor memory usage during peak traffic periods. Optimize memory-intensive pages and components. Implement caching strategies to reduce memory load. Contact support for memory upgrades if traffic consistently exceeds capacity.

How reliably your website serves visitors

This prevents unexpected memory limitations that could cause your website to become slow or unavailable during important traffic periods or business-critical times.

What we’re measuring: Stable memory allocation for public website
Target: Consistent memory performance
Why it matters: Memory inconsistency causes visitor frustration and lost business

What you can do: Report any sudden website slowdowns to support. Monitor for traffic patterns that correlate with performance issues. Implement load balancing strategies during expected traffic spikes.

How efficiently your website components work together

This ensures optimal positioning of your website and database components for fast page loading and reliable performance that visitors expect.

What we’re measuring: Optimal service placement for public website performance
Target: Fast inter-component communication
Why it matters: Poor deployment causes slow page loads and poor user experience

What you can do: Monitor page loading times and identify slow-performing sections. Report consistent performance issues to support for deployment optimization. Test website performance from different geographic locations.

How your website handles background processing

This monitors system memory that manages caching, indexing, and other background operations essential for serving content quickly and reliably to visitors.

What we’re measuring: System memory for website background operations
Target: Stable background processing memory
Why it matters: Issues affect search, caching, and overall site performance

What you can do: Monitor website search functionality and caching performance. Check for memory leaks in custom components.

How resilient your website is to infrastructure issues

This ensures your website is distributed across multiple availability zones so it stays online even if there’s an issue in one data center location.

What we’re measuring: Geographic distribution of website infrastructure
Target: Multi-zone deployment for high availability
Why it matters: Single-zone deployment creates risk of complete outages

What you can do: Evaluate your business requirements for uptime and availability. Plan failover testing to validate high availability setup.

How your website handles traffic and maintains uptime

This verifies your website has multiple running instances to ensure availability during maintenance periods and to handle traffic spikes effectively.

What we’re measuring: Number of active website instances
Target: Multiple instances for redundancy and load distribution
Why it matters: Single instance means no backup if problems occur

What you can do: Monitor website availability during maintenance windows. Contact support to configure additional instances for high-traffic sites. Plan replica scaling based on traffic patterns and business requirements.

Whether your content database has the latest improvements

This ensures your author database uses current version with performance optimizations and security updates for better content management experience.

What we’re measuring: Currency of author database version
Target: Recent database version with latest features
Why it matters: Outdated databases are slower and less secure

What you can do: Schedule database updates during content freeze periods. Back up critical content before updates.

Whether your website database performs optimally

This checks if your website database uses a current version for fast page loading, efficient traffic handling, and improved security for visitor data.

What we’re measuring: Currency of public database version
Target: Recent database version for optimal performance
Why it matters: Old database versions slow down your website

What you can do: Plan database updates during low-traffic periods. Test website functionality after database updates. Monitor page loading performance improvements after updates.

How much space you have for content and assets

This monitors storage space for your content management system to ensure you can continue creating content, uploading assets, and saving work without interruption.

What we’re measuring: Available storage for content management
Target: Adequate space for content creation activities
Why it matters: Full storage prevents content saving and asset uploads

What you can do: Regularly clean up unused assets and old content versions. Archive or delete outdated content. Monitor storage usage trends and plan upgrades before reaching capacity limits.

How much database space your website has available

This monitors storage for your website database to ensure continued functionality and ability to handle new content publication and visitor interactions.

What we’re measuring: Available database storage for website operations
Target: Adequate space for website data and growth
Why it matters: Full database storage can crash your website

What you can do: Monitor database growth trends and plan proactive storage upgrades. Clean up old log data and unused database entries. Contact support immediately if storage is nearly full.

Whether your URL redirects are properly managed

This ensures URL redirects are configured through proper channels for consistent behavior and to maintain good SEO rankings without broken links.

What we’re measuring: Proper redirect configuration management
Target: Centrally managed, trackable redirects
Why it matters: Improper redirects hurt SEO and create broken links

What you can do: Use only approved redirect management tools and interfaces. Document all redirect changes for future reference. Contact support before making complex redirect configurations.

How reliably your website redirects work

This ensures your redirect service has backup instances so URL redirects continue working during maintenance, preventing broken links for visitors.

What we’re measuring: Redundancy of redirect service instances
Target: Multiple redirect service instances
Why it matters: Single redirect instance means broken links during maintenance

What you can do: Test redirect functionality during maintenance windows.

Whether your website redirects work consistently

This validates that redirect configuration provides consistent behavior across all visitor sessions, ensuring smooth navigation experience without confusion.

What we’re measuring: Consistency of redirect configuration
Target: Uniform redirect behavior for all visitors
Why it matters: Inconsistent redirects confuse visitors and hurt user experience

What you can do: Test redirect behavior from different browsers and devices.

Security checks

Ingress access checks

Whether your Author ingress is protected from direct access

This checks the Author ingress configuration to ensure access is protected (for example by allowlisting, authentication, or mTLS). The check expects Author exposure to be secured by ingress-level protection mechanisms.

What we’re measuring: Whether Author ingresses are protected (true means protected)
Target: true (all Author ingresses protected)
Why it matters: Unprotected Author access can expose AdminCentral and content management endpoints to unauthorized users

What you can do: Review Author ingress annotations and confirm at least one protection mechanism is configured (auth secret, whitelist, or mTLS). Restrict access to trusted networks and administrative users only. Investigate any warning messages listing unprotected ingress names and harden those routes immediately.

Whether AdminCentral is blocked on public ingress routes

This checks public ingress rules for broad paths and verifies AdminCentral paths are not exposed without protection. If a public route includes /.magnolia, it should be denied or otherwise protected.

What we’re measuring: Whether public ingresses keep AdminCentral inaccessible from public routes (true means protected)
Target: true (no unprotected public AdminCentral exposure)
Why it matters: Exposing AdminCentral on public routes creates a high-risk attack surface for unauthorized access

What you can do: Inspect public ingress path rules and ensure /.magnolia paths are denied or protected. Use a deny location (or equivalent) for AdminCentral paths on public-facing ingresses. Review warnings naming unprotected ingresses and remediate those rules first.

Solr checks

Whether Solr ingress access is protected

This checks Solr ingress configuration to ensure search infrastructure endpoints are not exposed without protection. Solr ingresses should require access controls such as allowlisting, authentication, or mTLS.

What we’re measuring: Whether Solr ingresses are protected (true means protected)
Target: true (all Solr ingresses protected)
Why it matters: Unprotected Solr access can expose internal search endpoints, increase abuse risk, and leak operational data

What you can do: Review Solr ingress annotations and configure at least one protection mechanism (auth secret, whitelist, or mTLS). Limit Solr access to trusted internal clients and management networks. Investigate any warning messages listing unprotected Solr ingresses and secure them promptly.

Domains checks

DNS checks

Whether your domain points to the right servers

This checks if your domain name correctly resolves to Fastly’s CDN servers, ensuring visitors reach your website through the optimized delivery network.

What we’re measuring: DNS resolution target for your domain
Target: Points to Fastly or approved CDN servers
Why it matters: Wrong DNS settings prevent visitors from reaching your optimized website

What you can do: Verify your domain’s DNS settings point to the correct Fastly CNAME records. Contact your domain registrar to update DNS if pointing to wrong servers. Check for any custom DNS configurations that might override CDN routing.

How quickly DNS changes take effect

This ensures your DNS has a reasonable minimum cache time so changes don’t propagate too slowly, but also don’t cause excessive DNS lookups.

What we’re measuring: Minimum DNS cache duration
Target: At least 60 seconds
Why it matters: Too short TTL causes slow website loading due to constant DNS lookups

What you can do: Adjust your DNS TTL settings through your domain registrar or DNS provider. Set minimum TTL to at least 60 seconds for better performance. Avoid extremely short TTL values unless actively making DNS changes.

How long DNS information stays cached

This ensures your DNS cache time isn’t so long that important changes take too long to reach all visitors around the world.

What we’re measuring: Maximum DNS cache duration
Target: No more than 3600 seconds (1 hour)
Why it matters: Too long TTL delays DNS changes from reaching visitors

What you can do: Configure DNS TTL to be under 1 hour through your DNS provider. Balance between performance (longer TTL) and flexibility for changes (shorter TTL). Consider shorter TTL periods when planning infrastructure changes.

How much time before your domain expires

This monitors when your domain registration expires to prevent your website from becoming inaccessible due to an expired domain.

What we’re measuring: Days until domain registration expires
Target: At least 30 days remaining
Why it matters: Expired domains make your entire website inaccessible

What you can do: Renew your domain registration well before expiration. Set up auto-renewal with your domain registrar to prevent accidental expiration. Monitor domain expiration dates for all your domains and subdomains.

Certificate checks

How much time before your security certificate expires

This tracks when your SSL/TLS certificate expires to ensure your website remains secure and accessible without browser security warnings.

What we’re measuring: Days until SSL certificate expires
Target: At least 30 days remaining
Why it matters: Expired certificates cause security warnings and prevent visitor access

What you can do: Renew SSL certificates before expiration through your CDN provider or certificate authority. Set up automated certificate renewal if available. Monitor certificate expiration dates and plan renewals in advance.

Whether your security certificate is active

This ensures your SSL certificate’s start date has passed and is currently valid, preventing security issues from certificates that aren’t yet active.

What we’re measuring: Days since certificate became valid
Target: Certificate is currently active (0 or more days)
Why it matters: Invalid start dates cause security warnings and access problems

What you can do: Contact your SSL certificate provider if the certificate isn’t yet active. Verify certificate installation was completed properly. Check system clock settings if certificate timing seems incorrect.

Whether your security uses strong encryption

This verifies your SSL certificate uses secure encryption algorithms and doesn’t rely on outdated, weak encryption that could be compromised.

What we’re measuring: Strength of certificate encryption algorithm
Target: No weak or outdated algorithms detected
Why it matters: Weak encryption puts visitor data at risk and hurts SEO rankings

What you can do: Request a new certificate with stronger encryption if weak algorithms are detected. Contact your certificate provider to upgrade to current security standards. Avoid certificates using MD5, SHA-1, or other deprecated algorithms.

Whether your certificate covers all your website addresses

This ensures your SSL certificate is valid for all the domain names and subdomains visitors use to access your website.

What we’re measuring: Certificate coverage for all domain variants
Target: All hostnames properly covered by certificate
Why it matters: Uncovered hostnames cause security warnings for some visitors

What you can do: Use wildcard certificates or multi-domain certificates to cover all subdomains. Verify certificate includes www and non-www versions of your domain. Add any missing hostnames to your certificate or request a new one with proper coverage.

Whether your security certificate is properly connected

This verifies your SSL certificate has a complete chain of trust from your site certificate through intermediate certificates to a trusted root authority.

What we’re measuring: Complete certificate chain validation
Target: Valid chain from leaf through intermediate to root certificate
Why it matters: Broken certificate chains cause security warnings and access problems

What you can do: Install missing intermediate certificates in your certificate chain. Contact your certificate provider for the complete certificate bundle. Verify certificate installation includes all required intermediate certificates.

Whether your certificate is configured for web security

This ensures your SSL certificate has the proper permissions and usage flags set for serving secure web traffic to your visitors.

What we’re measuring: Certificate key usage permissions
Target: Appropriate usage flags for web serving
Why it matters: Wrong key usage can cause certificate validation failures

What you can do: Request a new certificate with proper key usage extensions if current certificate has restrictions. Work with your certificate provider to ensure web server authentication is permitted. Verify certificate was issued for the correct intended use.

Miscellaneous checks

Subscription checks

Whether emergency contacts are defined for your subscription

This checks that your subscription has at least one emergency contact with a valid email address or phone number. Emergency contacts are used when Magnolia needs to escalate critical incidents outside normal support hours.

What we’re measuring: Number of emergency contacts with a valid email or phone number
Target: min 1 valid emergency contact
Why it matters: Missing or incomplete emergency contacts can delay escalation during production incidents

What you can do: Ensure every emergency contact has at least an email address or phone number. Review any warning messages listing contacts with missing details and update them with your {solution} contact. Keep emergency contacts current when team members or on-call responsibilities change.

Whether day-to-day subscription contacts are defined

This checks that your subscription has at least one general contact with a valid email address or phone number. These contacts are used for routine operational communication and support coordination.

What we’re measuring: Number of subscription contacts with a valid email or phone number
Target: min 1 valid contact
Why it matters: Missing or incomplete contacts make it harder to reach the right people for day-to-day support

What you can do: Ensure each listed contact has at least an email address or phone number. Review warning messages for contacts with missing details and provide complete information to your {solution} contact. Update contacts when responsibilities or team membership changes.

Whether Technical Account Managers (TAMs) are defined for your subscription

This checks that your subscription has at least one TAM contact with a valid email address or phone number. TAMs are your primary technical points of contact for ongoing platform guidance and support.

What we’re measuring: Number of TAM contacts with a valid email or phone number
Target: min 1 valid TAM contact
Why it matters: Missing TAM contact details can slow technical coordination and account-level support

What you can do: Ensure each TAM entry has at least an email address or phone number. Review warning messages for TAMs with missing details and update them with your {solution} contact. Confirm TAM assignments remain accurate after organizational changes.

Whether Customer Success Managers (CSMs) are defined for your subscription

This checks that your subscription has at least one CSM contact with a valid email address or phone number. CSMs help coordinate communication and alignment between your team and Magnolia.

What we’re measuring: Number of CSM contacts with a valid email or phone number
Target: min 1 valid CSM contact
Why it matters: Missing CSM contact details can disrupt account communication and planning

What you can do: Ensure each CSM entry has at least an email address or phone number. Review warning messages for CSMs with missing details and update them with your {solution} contact. Keep CSM information current when account ownership changes.

Whether CDN provider information is set for all production clusters

This checks that every production cluster in your subscription has a CDN provider recorded (for example Fastly or not managed). This helps Magnolia understand who operates the CDN layer for each environment.

What we’re measuring: Whether all production clusters have CDN provider information configured
Target: All production clusters set
Why it matters: Missing CDN metadata makes it harder to operate, troubleshoot, and plan changes across your environments

What you can do: Review warning or error messages listing clusters without CDN information. Work with your {solution} contact to confirm the correct CDN provider (or not managed) for each production cluster. Update cluster metadata when CDN ownership or provider changes.

Whether source control information is recorded for your subscription

This checks that your subscription includes source control details so Magnolia can support your delivery pipelines. The check passes when source control is marked as Magnolia-managed, or when both a provider name and repository URL are provided for customer-managed source control.

What we’re measuring: Whether complete source control information is configured
Target: Source control info set
Why it matters: Incomplete source control details make it harder to support deployments, pipeline issues, and release coordination

What you can do: If source control is customer-managed, provide both the provider name and repository URL. If Magnolia manages your source control, ensure it is marked as managed. Review warning messages for missing name or URL fields and update the information with your {solution} contact.

Whether a platform update tier is configured for your subscription

This checks that your subscription has a platform update tier defined. The update tier records which maintenance and update schedule has been agreed for your environment.

What we’re measuring: Whether a platform update tier is set in subscription settings
Target: Update tier set
Why it matters: Without a defined update tier, maintenance planning and platform update coordination are harder to align with your expectations

What you can do: Go to Subscription > Platform Update tiers in the {ui} and select the tier that matches your agreement with Magnolia. If no tier is available or you are unsure which tier applies, contact your {solution} representative. Review this setting when your update preferences or contract terms change.