Block themes do not change the fundamentals of hosting, but they do change where performance bottlenecks appear. This is where the role of the web host becomes clearer. Infrastructure alone does not make a site fast; poorly tuned infrastructure becomes apparent in modern WordPress workflows, especially when dynamic blocks, the Site Editor, previews, and logged-in sessions are involved.

To understand why, it helps to look at what actually happens during a page request and how hosting decisions affect the user experience when a block-based architecture is used.

What happens when a WordPress page is requested

Let’s walk through a simple request that returns a 200 OK response.

1: The browser sends the request

A user enters a URL or clicks a link. If the server’s IP address is not already cached, the browser performs a DNS lookup. It then opens a TCP connection and negotiates a secure TLS session.

Before WordPress is involved, the request passes through the web server and any configured layers such as firewalls or reverse proxies.

2: Cache check

The server checks whether a valid cached version of the requested page exists.

If a full-page HTML cache is available and valid, WordPress does not execute. The cached response is returned immediately.

If no cache entry exists, or if caching is intentionally bypassed for logged-in users, previews, or specific endpoints, the request continues to WordPress.

3: WordPress fires up

WordPress loads its core files, active plugins, and the active theme. It initializes hooks and prepares to resolve the request.

At this stage, WordPress does not yet render output. It determines what content is being requested.

4: Main query resolution

Using rewrite rules and query variables, WordPress builds and executes the main database query. It determines whether the request is for a single post, page, archive, search result, or another content type.

Only after this does template selection begin.

5: Template resolution

This is where block and classic themes begin to differ structurally.

Classic themes

WordPress evaluates the template hierarchy and selects the appropriate PHP template file, such as single.php, page.php, or archive.php. That file contains PHP logic that outputs HTML directly.

Block themes

WordPress checks whether a customized block template exists in the database. If one exists, it takes priority. If not, WordPress falls back to the block template file included in the theme, such as single.html or index.html.

The selected template is then processed through the block rendering system.

6: Layout assembly

Classic themes

The layout is constructed through PHP templates. These templates combine markup, logic, and function calls to produce HTML output.

Block themes

The layout is assembled from block templates, template parts, and post content. Block markup is parsed, and each block is rendered into HTML before the final output is generated.

7: Content structure

Classic themes

Post content is primarily stored as HTML in the database. During output, WordPress applies filters, shortcodes, and other processing before rendering.

Block themes

Block content is stored as HTML with embedded block metadata, for example:

<!-- wp:image {"id":123} -->

<img src="proxy.php?url=logo.png">

<!-- /wp:image -->

When WordPress processes this content, it parses the block structure, understands attributes and nesting, and applies block-level attributes and styles such as spacing, alignment, and typography before generating the final HTML.

8: Dynamic rendering

Dynamic rendering exists in both classic and block themes. Many classic themes rely on custom queries, widgets, or shortcodes that generate output at runtime.

In block-based architectures, dynamic behavior is formalized through dynamic blocks. For example, a Query Loop block generates its markup during the request using PHP rather than storing static HTML in the database.

When full-page caching is bypassed, this rendering workflow happens on every request.

9: Styling

For classic themes, styling is typically delivered through static CSS files enqueued by the theme.

For block themes, global styles defined in theme.json and block metadata allow WordPress to automatically generate consistent CSS. This reduces the need for large handcrafted stylesheets and centralizes design configuration.

10: Final output

After templates, content, blocks, and styles are processed, WordPress produces the final HTML response.

The server sends the payload to the browser. If configured, the response may then be cached for future requests.

Where block themes shift the load

The request lifecycle you just walked through applies to both classic and block themes. WordPress still resolves queries, selects templates, executes PHP, and returns HTML.

What changes with block themes is not the foundation, but where work happens and when it cannot be skipped.

First, templates can live in the database. When a user edits a template in the Site Editor, WordPress stores that version and prioritizes it over the file in the theme directory. This adds flexibility, but it also means deployments and cache invalidation need to account for database-stored templates.

Second, dynamic blocks make runtime rendering more visible. Classic themes can generate dynamic output through custom queries, widgets, or shortcodes. Block themes formalize this pattern through dynamic blocks, such as the Query Loop block. When full-page caching is bypassed, these blocks execute PHP during the request.

Third, editor workflows rely heavily on REST endpoints. Saving templates, updating global styles, previewing changes, and interacting with patterns generate uncached requests. These paths depend directly on PHP execution, database performance, and object caching.

Finally, global styles defined in theme.json centralize design decisions. When styles or template structures change, cache coordination becomes more important to ensure that visitors and editors see updated output immediately.

None of these shifts requires a different type of hosting. They do make certain infrastructure weaknesses more visible, particularly in uncached and logged-in scenarios.

With that in mind, the next step is to look at what a well-configured hosting environment should handle in a block-based setup.

Hosting considerations for block-based sites

Block themes do not introduce new hosting requirements. They make existing ones more important to get right.

A well-configured environment should account for both cached and uncached paths, especially for editors and logged-in users.

Coordinated caching across layers

Full-page caching remains the most effective performance layer for anonymous traffic. Public pages should be cached aggressively, while previews, logged-in sessions, and specific endpoints are automatically bypassed.

Object caching also plays a significant role. By storing repeated query results and computed data structures in memory, an object cache reduces database load and improves both frontend and backend responsiveness.

Cache invalidation needs to be coordinated. When content, templates, or global styles are updated, related pages should refresh promptly. Poor cache coordination can result in outdated layouts, inconsistent styles, or confusing preview behavior.

A CDN complements this setup by caching static assets such as images, fonts, and scripts closer to visitors.

Caching is not about one layer. It is about how these layers work together.

PHP capacity and runtime performance

When full-page caching is bypassed, WordPress executes PHP to resolve queries, render templates, and process dynamic blocks.

This makes PHP capacity planning important. The environment should provide enough PHP threads to handle expected concurrency without queue buildup. Memory limits should be configured to prevent swapping under load.

OPcache should be enabled and properly sized so that PHP bytecode does not need to be recompiled repeatedly. During deployments, OPcache should refresh so updated code runs immediately.

These practices apply to all WordPress sites, but block-based workflows can make performance issues more noticeable when rendering is dynamic.

Database and object caching

Block templates customized in the Site Editor are stored in the database. Block content includes structured metadata that WordPress parses before output. While this processing is efficient, it still depends on database responsiveness when caching is bypassed.

A persistent object cache reduces repeated queries and helps stabilize performance for both frontend visitors and editors working inside the dashboard.

Observability and monitoring

As more activity shifts into runtime paths, visibility becomes more important. Hosts and site owners should monitor:

• Cache hit ratios
• PHP worker utilization and queue length
• Database query performance
• REST API response times
• Time to first byte for cached and uncached requests

Block themes do not require specialized infrastructure. They do make it easier to see when infrastructure is loosely configured.

Running WordPress the way it works today

Block themes do not change what WordPress needs from hosting. They make it clearer when those needs are not met.

When templates live in the database, when dynamic blocks render at runtime, and when editors rely on uncached REST requests, infrastructure is no longer invisible. It either supports the workflow smoothly or it gets in the way.

That is where managed hosting for WordPress makes a difference.

At Kinsta, the entire stack is built specifically for how WordPress operates today, from coordinated caching and persistent object caching to tuned PHP performance and global CDN delivery on powerful cloud infrastructure. The goal is to ensure both visitors and editors experience consistent performance, even when rendering happens dynamically.

Block-based WordPress is not heavier. It is more transparent. And when the foundation is solid, that transparency works in your favor.

The post How modern block themes are changing WordPress hosting appeared first on Kinsta®.

Many agencies subscribe to third-party WordPress Management Tools (or Centralized Dashboards) to help them manage WP Admin access across multiple sites. However, these services come at a cost that, for an agency with over 50 sites, can reach up to $1,500/year—not to mention the time lost in setup and maintenance.

To eliminate this inefficiency, we’ve launched a native solution that enables your team members to automatically authenticate to the WordPress admin panel directly from your MyKinsta dashboard with a single click. This feature saves your agency time by removing the need to manage credentials and two-factor authentication for each login, allowing your team to focus on higher-value activities while improving security and productivity.

Let’s dive into WP Admin auto-login and find out why it’s such a powerful feature for agencies.

Reclaiming Efficiency with Kinsta’s WP Admin auto-login

For an agency managing multiple sites, time is a scarce resource. Every single step in a workflow consumes time and energy, and often the “in-between” tasks—like logging into a WordPress dashboard—are underestimated.

Think about it: Every time a team member needs to access a site’s admin, they have to search for the domain, retrieve credentials, find the login URL (which is often customized), and wait for a 2FA code. Multiply this by dozens of logins per day, and you’ve identified a major source of inefficiency and stress.

The problems caused by manual login impact different roles within your agency:

• Project Manager: Managing access is tough. If different developers have different site assignments, the PM must provide everyone with proper access. This increases security risks and complicates operations. Third-party tools help, but also raise costs.
• Technical team: Accessing the WordPress admin for every bug report takes time, especially when a site uses a custom login URL for security.
• Marketing Specialist: Updating a tracking pixel across 20 sites means spending many minutes copying and pasting credentials.

With Kinsta as your hosting partner, there’s no need to manage credentials for multiple WordPress sites. You can simply access admin panels with one click.

How Kinsta’s WP Admin auto-login works

To log in automatically to WP Admin in Mykinsta, navigate to Sites > sitename > Info, and click on Log in to WP Admin.

If your MyKinsta email matches an existing WordPress user’s email, you are directly logged into your WordPress admin.

If no WordPress user exists with the same email as your MyKinsta account, you’ll be prompted to create a new Administrator account using that email address. This step is required to access WordPress via auto-login from MyKinsta.

To create the new WP Admin user and log in automatically, click Create admin and log in.

Please note that the WP Admin auto-login feature requires pop-ups to be enabled in MyKinsta. If pop-ups are disabled, you will see a Pop-up blocked message. Follow the instructions in our docs to fix this issue, or refer to your browser’s documentation.

Kinsta’s WP Admin auto-login does not replace standard credential-based authentication. Once you’ve created a new user via WP Admin auto-login, if you want to log in manually, you need to reset your WordPress password by clicking Lost your password? on the WordPress login screen. Then, just follow the link you will receive via email to set your new password.

WP Admin auto-login is enabled by default for all your websites. Company Owners, Company Administrators, and Company Developers can enable/disable it on a per-site basis under Sites > sitename > User management > WP Admin auto-login > Disable.

Security and Governance with Kinsta’s WP Admin auto-login

Keeping things simple should not weaken security. Third-party management tools usually require plugins that may introduce vulnerabilities. Kinsta’s WP Admin auto-login streamlines agency workflows while enforcing governance without compromising your security. This centralized authentication system offers several benefits:

• Granular site-level control: Not all sites need the same settings. Your agency might manage high-traffic e-commerce sites with strict security protocols alongside smaller portfolio websites. As a company owner or administrator, you can granularly control which sites have auto-login enabled directly from the MyKinsta user management page.
• No passwords to store: With WP Admin auto-login, your team members don’t need to store or share credentials for every site. This eliminates risks like weak passwords, shared credentials, or forgotten 2FA setups.

Native Integration with MyKinsta SAML SSO

Kinsta’s WP Admin auto-login integrates natively with Kinsta SAML SSO, bringing unique benefits to your agency’s governance, including enhanced security and greater fluidity.

If you are using an Identity Provider (IdP) like Microsoft Entra ID, Google Identity Platform, or Okta, you can centralize the entire access lifecycle at the IdP level.

You can decide which members of your team can access MyKinsta with the default Company Developer role. You can then change the default role or modify a specific user’s role in MyKinsta. If you leave the default Company Developer role, the user will be able to access all of your agency’s sites through WP Admin auto-login.

If you change an individual user’s role, for example, to Site Developer, the authorized team member will only be able to use WP Admin auto-login on the sites they have access to.

With Just-In-Time (JIT) provisioning, the process is even simpler: authorized users at the IdP level can access MyKinsta without a manual invite. Upon their first login, the system generates a new account, and they can immediately use the WP Admin auto-login to access client sites based on their assigned roles (e.g., Company Developer).

Here is the step-by-step process for a typical onboarding process:

• A new team member is added to your environment at the IdP.
• Your new employee logs into MyKinsta via SAML SSO.
• The system automatically creates a new MyKinsta user with the Company Developer role (or another role if you have changed the default settings), and the new team member can immediately start working in MyKinsta.
• The user navigates to Sites > sitename > Info and clicks Log in to WP Admin.
• If this is their first login, the system automatically creates a new WordPress user, and your new team member is up and running in seconds.

Why Kinsta’s WP Admin auto-login is different

Although one-click login is now considered standard in managed hosting, most implementations on the market have documented limitations that often force agencies to revert to manual authentication just when they are trying to streamline processes while maintaining high security.

Kinsta’s WP Admin auto-login is different because it was designed to overcome the constraints of traditional automatic login:

Custom Login URLs: Many agencies rename the login page of their clients’ sites to strengthen WordPress admin security (for example, from /wp-admin to /my-secret-login). Providers such as WP Engine expressly state that their Seamless Login does not work for “sites that have a custom login page URL that is not wp-admin or wp-login.php.” Kinsta’s WP Admin auto-login works seamlessly with custom login paths without any additional configuration.

Multisite Support: On many hosts, one-click login is not compatible with multisite installations. Flywheel does not guarantee that its Seamless Login will work properly when WordPress Multisite is enabled. WP Engine explicitly states that its Seamless Login does not work for multisite installations. Kinsta’s WP Admin autop-login fully supports multisite installations, assigning Super Admin privileges to the user created via SSO.

Other common limitations to using one-click login include 2FA, transferable sites, and password-protected sites, though most hosting providers leave their one-click login services undocumented.

Conversely, Kinsta’s WP Admin auto-login is fully compatible with two-factor authentication, staging environments, and password-protected sites.

Use Case Scenarios

To understand the importance of Kinsta’s WP Admin auto-login for your agency, let’s put ourselves in your team members’ shoes.

Debugging under pressure

Suppose your client’s website receives a 500 Internal Server Error during a product launch. Your IT team can’t waste time searching for credentials; they need to act immediately. They log into MyKinsta with SAML SSO, navigate to Sites > sitename > Info > Log in to WP Admin, and they’re in. With Kinsta’s WP Admin auto-login, a process that could take several minutes takes only 10 seconds or less.

Massive maintenance and marketing

Need to update a tracking pixel or change a setting on 50 client sites? Instead of logging in 50 times, your Marketing Specialist can hop in and out of each WordPress dashboard as easily as switching between browser tabs. One click, and they’re on every one of your clients’ sites. The time savings from Kinsta’s WP Admin auto-login aren’t measured in seconds but in minutes.

Quick and secure offboarding

Think about when one of your employees leaves your team. Without centralized access control, you would have to manually map and delete that user from all your WordPress sites, risking forgetting some. If you have enabled mandatory SSO and WP Admin auto-login in MyKinsta, you won’t have to worry about this, as you can simply revoke their access in your IdP, and their access will be automatically blocked in MyKinsta and across all your clients’ WordPress sites.

Access governance per site

In some cases, you may want to enable auto-login for users on some of the sites you manage but not on others. This may be the case, for example, if you have sites that require more rigorous security measures. In such cases, you may want to disable automatic login on a specific site but not on others. With Kinsta’s WP Admin auto-login, this is possible. Navigate to Sites > sitename > User management > WP Admin auto-login, click Disable, and you are done.

More time for high-value activities

At Kinsta, we strive to simplify site management, especially for agencies with dozens or hundreds of WordPress sites. Kinsta’s WP Admin auto-login is another piece that adds to MyKinsta’s SAML SSO, code repo integrations, automation tools, and Kinsta API.

With this new feature, your agency’s teams will spend less time logging into your clients’ sites, have granular access governance, and can focus on the tasks that matter most to you without worrying about access management.

WP Admin auto-login is available on all Kinsta plans at no extra cost. Ready to turn MyKinsta into your centralized command center? Check out our plans or contact sales to learn more.

The post Manage hundreds of sites with Kinsta’s WP Admin auto-login appeared first on Kinsta®.

You can’t always be present if your site crashes during peak times, such as Black Friday or major campaigns. That’s why notifications are not just technical; they are vital for anyone managing an online business or providing essential services.

This article gives an overview of essential notifications for WordPress site management and explains how Kinsta customers can enable automatic alerts via the MyKinsta dashboard and the Kinsta API.

Let’s dive in!

Essential monitoring and notification tools for managing strategic websites

Businesses and mission-critical sites, such as e-commerce and university websites, need seamless, round-the-clock monitoring. This ensures a site is not only online but also performing at its peak.

Managing a strategic website is like conducting an orchestra. You need to track several areas at once. Here are the main areas for real-time notifications.

Uptime and critical errors

For an e-commerce site or an essential service provider, critical website errors can immediately cause financial loss or service interruptions. Inadequate hosting can lead to downtime, risking brand reputation and user trust. Yet, even with high-performance cloud hosting, unforeseen issues can arise. This makes a robust uptime monitoring system an absolute necessity.

Such a system should monitor errors like 500 Internal Server Error, 502 Bad Gateway, 504 Gateway Timeout, and database connection errors. Some of the most popular monitoring and notification tools available on the market include the following:

• UptimeRobot: This service offers real-time monitoring of uptime, SSL certificates, ports, and cron jobs. It allows you to set up instant alerts and includes an API for integrating it into your workflow.
• Better Stack: An AI-native platform offering infrastructure monitoring, status pages, log management, and distributed tracing. It also provides an API that lets you automate workflows and integrate Better Stack with the tools you use daily.
• Pingdom: Offers several types of monitoring, including Real User Monitoring (RUM), transaction monitoring, page speed analysis, and uptime monitoring. You can set up instant alerts via text message or email about issues such as error messages, HTTP status codes, and content changes.

Performance and scalability

A website must remain responsive, even during sudden traffic surges. Fast, scalable cloud hosting forms the foundation, but you also need dedicated monitoring. Such a system flags any performance drop as soon as it happens.

Monitoring is critical if your hosting is unreliable. Ironically, if your host can’t support your mission, your site might fail when your business succeeds.

The main factors to monitor are PHP threads, Time to First Byte (TTFB), and database load. When queries slow down, your entire site slows down. Monitoring tools like those below help ensure your visitors get the experience they expect.

• New Relic: New Relic is a powerful performance monitoring tool installed in your hosting environment that analyzes every process on your website. With New Relic, your IT team can identify PHP threads or database queries that are slowing down your site. It allows you to identify plugins or scripts that are not optimized for performance, spot potential conflicts, and resolve structural bottlenecks before they affect the end-user experience.
• Pingdom: As mentioned in the previous section, Pingdom is a tool for uptime monitoring. However, this powerful monitoring tool’s real strength lies in Real User Monitoring (RUM) and synthetic speed tests. Pingdom tests your site from different geographic locations every few minutes, measures TTFB, and sends you a notification if server response times slow down.

  

• GTmetrix/PageSpeed Insights: These are two powerful performance monitoring tools that analyze page structure and provide key metrics for optimizing content. Both services provide APIs for automated testing and for sending notifications when the performance score falls below a set threshold.

  

• Datadog: Datadog is an enterprise-level tool designed for high-traffic websites, including large e-commerce sites, news sites, and university portals. Datadog aggregates traffic and server load data into useful metrics and diagrams that provide essential information to improve your website’s UX and optimize its performance.

Security and SSL

Monitoring is perhaps most critical when it comes to security, because ensuring the site’s resilience against attacks and the integrity of the stored data is vital to you and your customers.

Security monitoring should cover SSL certificate validity, DNS and domain integrity, unauthorized access attempts, and vulnerabilities.

• Sucuri/Wordfence: These are two powerful WordPress plugins that offer proactive detection and monitoring, intrusion protection and prevention, firewalling, and real-time alerts for security vulnerabilities (see also our comparison of Sucuri and Wordfence).

  

• Other security monitoring tools include HackerOne, Detectify, Qualys, and many others.

Bandwidth Overages

Monitoring bandwidth consumption ensures that your site’s infrastructure can handle the load generated by site views, especially when your site receives a high traffic volume (the holiday season for an e-commerce website or the pre-enrollment period for an educational site).

• Cloudflare is the most popular and powerful bandwidth monitoring tool. It acts as a proxy, analyzing and filtering all incoming traffic, provides a firewall with built-in DDoS protection to guard against these attacks, and offers analytics to monitor your site’s activity, including bandwidth usage and savings. Cloudflare also provides automatic notifications that vary depending on your plan.

  

• cPanel/Plesk: Hosting management dashboards typically include analytics modules that track daily and monthly bandwidth usage. You can often set warning thresholds to receive a notification when you exceed 80% of the server’s monthly limit.

It should now be clear that implementing a comprehensive monitoring and notification system is essential. Unfortunately, while choosing the right tools is challenging enough, learning and configuring them can be even more problematic.

This process requires time and resources that could be put to better use. You also have to consider the additional costs these tools often entail. Some offer free plans, but they are often not an option for high-traffic sites.

Kinsta customers have it easy because Kinsta offers an advanced, comprehensive monitoring system that covers all components of your website’s success, including uptime, performance, security, and bandwidth consumption. It also has a customizable notification system that alerts you to critical events on your site or when resource consumption thresholds are reached.

That said, let’s take a closer look at the monitoring and notification tools you can easily enable from your MyKinsta dashboard.

Monitoring and notifications at Kinsta

Kinsta constantly monitors your site’s uptime and runs continuous security scans. If you’ve selected Kinsta as your hosting partner, you may occasionally receive notifications about account statuses or events that require your attention.

Some notifications are mandatory and cannot be disabled. These are system messages that provide information about critical updates or changes, such as PHP deprecation warnings. They are sent via email to company owners, company administrators, company developers, site developers, and site administrators.

Then, according to your preferences, you can enable or disable changes in MyKinsta. To access the notification configuration page, click your name in the upper right corner of the MyKinsta dashboard, then click User Settings.

Next, in the left sidebar, select Notifications.

The Notifications page is divided into sections, each dedicated to a specific notification type. Let’s take a closer look at each of them.

Plan limit alerts

Each Kinsta plan includes a set amount of allocated resources, including monthly visits, server bandwidth, SSD disk space, and CDN bandwidth. If your websites consume more resources than allocated during the billing period, they won’t go down; however, you may incur overage charges.

However, if you enable plan limit alerts, you will be notified before you exceed your plan’s resource limits. You will receive an email notification when you reach 80% and 100% of your limits. These notifications allow you to promptly investigate and take action to avoid unexpected overage fees.

You can view the same notification in MyKinsta by clicking the Notifications icon in the top right corner of the navigation bar.

Below are the types of plan-limit notifications you may receive from Kinsta.

Visits

The strategy you adopt for site visits will differ depending on whether you are receiving an overload of genuine or undesired visits. For instance, you may have launched a marketing campaign or received backlinks from a high-traffic site. However, a sudden spike in visits could also be due to suspicious activity from specific IP addresses, hotlinking, or bot traffic.

You can start your audit by checking your site’s analytics page. MyKinsta provides information to help you identify the top countries, cities, and IP addresses of your users. To view this information, navigate to Sites > site name > Analytics, then click Geo & IP.

If you notice an overload of visits from a country or city that is not part of your target market, you can adopt two different strategies:

• You can contact our support team to set up geo-blocking with server-side rules to filter traffic from those countries.
• You can redirect traffic from specific countries or cities by enabling IP geolocation in MyKinsta. This strategy is not intended to restrict access from unwanted sources. Rather, it is designed to direct your visitors to the resources intended for them. The goal is to best serve your target markets.

Disk space

If the problem is disk space consumption, you may realize that your images and media files are not optimized. There are several ways to reduce the space your media uses. First, optimize your media before uploading. However, for high-volume sites, we recommend hosting large videos and images on external platforms such as YouTube or Vimeo, or on a dedicated cloud storage platform, to keep your WordPress installation light and fast.

Another option is to purchase our disk space add-on to increase disk storage without upgrading your plan. This add-on is available in 20 GB increments for $20 per month, and you can add as many as you need to your plan. This allows you to avoid the overage fee without upgrading to a higher plan. Alternatively, you can review your media storage strategy by moving your media to an off-site cloud storage site.

Server and CDN bandwidth

Receiving a notification for server bandwidth consumption may mean that your site is not optimized for performance. Enabling Kinsta’s Content Delivery Network (CDN) and Cloudflare’s Edge Caching can prevent many bandwidth issues. Enabling our CDN also unlocks image optimization with automatic conversion to WebP.

Another possible cause of excessive bandwidth consumption is hotlinking. If a website is hotlinking from your site, you can simply contact our support team to enable server-side hotlink protection.

Another key metric for resource consumption is CDN bandwidth. Abnormal CDN bandwidth consumption may mean that a lot of data is being transferred from Cloudflare’s servers to your site visitors. If this value looks excessive, you may want to investigate further. Common causes include:

• Unoptimized static files: You may have many big images, perhaps directly uploaded as raw files from your DSLR. As a first step, check if your images are optimized. If not, enable automatic image optimization in MyKinsta.
• Bot and Scraping Attacks: Many malicious bots scan your site’s content and download all the code and images. As with server bandwidth consumption, there are several strategies you can implement to combat this, such as blocking or geo-blocking specific IP addresses, moving video content to video-sharing platforms like YouTube or Vimeo, and enabling content delivery network (CDN) image compression.

WordPress site monitoring

Manually checking dozens or hundreds of client sites is simply impossible. Therefore, a notification system that sends automatic alerts or emails whenever an issue interrupts your WordPress site’s operation is vital.

If your site isn’t hosted on Kinsta, then you’re probably paying for one or more third-party tools to send you messages or emails when critical events occur. Kinsta customers don’t have to worry about paying for or configuring an additional service to monitor site uptime and health because Kinsta automatically monitors your WordPress site every three minutes, 480 times a day. If our system detects that your site is not loading, it immediately notifies our engineers, who then take action to restore it.

In addition, when WordPress site monitoring notifications are enabled in MyKinsta, we’ll send you a notification every time we detect one of the errors below in 3 consecutive checks:

• Site Errors
• DNS Errors
• SSL Errors
• Domain Expiration

Since the notification is sent only after the third check, you will not be notified of every minor error. You will only be emailed if the problem persists.

The following image shows an error notification email sent from a test WordPress site hosted by Kinsta.

The next image shows a PHP error in MyKinsta Notifications.

Finally, the next image shows a domain expiration error notification:

What to do when you receive a WordPress site monitoring notification

A site error notification means that your visitors cannot view your site content. These errors often appear as 5xx error codes, such as 500 Internal Server Error or 502 Bad Gateway.

There are several steps you can take to try to restore your WordPress site. First, try restarting your site’s PHP engine. If you recently installed or updated a plugin or theme, temporarily disable it to check for conflicts.

If these initial attempts do not resolve the issue, proceed to the next step: check the Kinsta APM tool and the Log viewer in your MyKinsta dashboard.

Kinsta APM can help you identify which plugin, query, or script might be exhausting your site’s PHP memory limit or generating other conflicts. To begin monitoring, go to Sites > APM and click Enable API. Then, set a monitoring time and wait for the tool to record the site’s activity. For more information on Kinsta APM, please refer to the online documentation.

Another place to look for the cause of a problem is the server log. You’ll find the log under Sites > sitename > Logs. Three tabs provide the error.log, kinsta-cache-perf.log, and access.log files.

These files can help you identify the type of error that caused your site to block. Examples of these errors include PHP syntax errors, missing files, script timeouts, conflicting plugins, caching errors, and the IP addresses from which requests to your site originate.

If you have tried everything and exhausted all available options, you can always open a chat with our support team. Our expert engineers will be happy to help you troubleshoot and fix the problem.

If you received a DNS Errors notification, it means that our servers can no longer resolve your domain name. There can be several causes of this error. It could be a client-side error, such as a problem with your network or internet connection. It could also be a problem with misconfigured DNS settings, meaning your site’s DNS is not pointing to Kinsta correctly.

First, check the status of your domain registrar. Log in to your DNS registrar dashboard (Cloudflare, GoDaddy, Namecheap, Bluehost, etc.) and confirm that the A record is pointing to the correct IP address for your site, which you can find in the MyKinsta dashboard under Sites > Info.

Our documentation helps you to correctly point your domains to Kinsta, update your DNS settings, and update your name servers.

Lastly, if you receive an SSL error notification, it means that your SSL certificate has expired. Without a valid certificate, browsers will block access to your site and display a security warning. In MyKinsta, navigate to Sites > sitename > Domains and verify that the domain is correctly pointing to Kinsta’s IP address (automatic renewal will fail if the DNS is not configured correctly). If you are using a custom certificate, confirm that it has not expired and re-upload it.

Kinsta Automatic Updates

If you purchased the Kinsta Automatic Updates add-on, enabling Kinsta Automatic Updates notifications will send you automatic emails and dashboard notifications for weekly updates, successful updates, and failed updates.

Kinsta Automatic Updates are performed on the server side and are designed to ensure your site does not go down due to update issues. This is because the software performs a visual regression test on your site before and after the update. If the test fails, Kinsta rolls back the changes and notifies you.

The following images show email notifications for weekly updates, successful updates, and failed updates.

Vulnerability notifications and monthly vulnerability digest

Our systems perform continuous security checks across our entire infrastructure to detect malware and other vulnerabilities.

By enabling Vulnerability notifications, Company owners, Company/Site administrators, and Company/Site developers will receive an email notification every time a high-severity vulnerability (severity score of 7 or higher) is detected in your plugins or themes, also including details on how to address the plugin/theme issue promptly.

Vulnerability notifications only concern high-risk vulnerabilities. Opting in to the Monthly vulnerability digest will provide you with a monthly report of all vulnerabilities in your plugins and themes.

The Notifications configuration page includes additional options for enabling invoices in email and subscribing to our newsletters, research invitations, and Automatic monitoring alerts.

Although MyKinsta includes a comprehensive notification system, developers and agencies often need more granular control over notifications. Furthermore, these teams often need to automate workflows and integrate tools and hosting services with their internal collaboration and communication platforms, such as Slack, Trello, their CRM, or their custom dashboard.

This is where the Kinsta API can significantly impact your team’s workflow.

Taking notifications to the next level with the Kinsta API

The Kinsta API is a powerful REST API that lets you retrieve data from your Kinsta-hosted websites and perform operations on environments and sites.

The Kinsta API enables growth-oriented agencies to create smart, fully automated monitoring and notification systems. Below are some ways to improve your site management and monitoring workflows:

• You can go beyond the default MyKinsta notification settings. If you have enabled resource consumption notifications in MyKinsta, you will receive notifications at 80% and 100% of your resource limits. With the Kinsta API, you could add more checks or monitor resource consumption at specific time intervals.
• You can configure your script to send notifications on your preferred messaging or communication platforms, including Slack, Telegram, SMS, or a custom dashboard.
• You could push notifications a step further by integrating your Kinsta hosting with third-party applications and custom environments. As an example of this, in a previous article, we explained how to create a PHP script that uses the Kinsta API to retrieve the URLs of your Kinsta-hosted sites, sends them to the PageSpeed Insights API, receives a set of Core Web Vitals metrics, and sends a message to a Slack channel if the metrics fall below a specified threshold.

With the Kinsta API, you can access the heart of your website to perform operations such as:

• Monitoring background tasks such as backups, cache clearing, or environment operations.
• Retrieve analytics data, including resource usage, PHP requests, bandwidth consumption, and more.
• Check site and environment status.
• Programmatically toggle tools such as the PHP engine or launch a manual backup.

How to build your custom notification engine: A practical workflow

Creating a customized notification system is a 4-step process.

1. Set up the trigger

Since the Kinsta API uses REST requests instead of push events, you need to set up a trigger to query the API at regular intervals. To do this, you can set up a cron job on your WordPress site, or use GitHub Actions or automation tools such as Make.com or Zapier.

2. Retrieve data with the Kinsta API

The Kinsta API provides a considerable set of endpoints for implementing an automated notification system. Below are some endpoints and their respective use cases.

The /analytics endpoint allows you to monitor resource consumption.

• /analytics/cdn-bandwidth and /analytics/bandwidth provide data on CDN and server bandwidth consumption. Strategically monitoring these endpoints lets you identify traffic anomalies without accessing MyKinsta. A sudden spike in bandwidth consumption may indicate a hotlinking attack or an attempt to exhaust your resources via bots. You could use these endpoints to create an alert that notifies you in real time on Slack or Telegram when there is abnormal bandwidth consumption requiring your attention.
• The /analytics/visits endpoint allows you to detect unexpected traffic spikes. To prevent DDoS or brute-force attacks, you can create a script that sends you a Slack notification prompting you to check the logs. Even better, you could create a script that automatically blocks the malicious IP address from which the requests originate. You can also use this endpoint to observe and report on the effects of your promotional campaigns in real time, eliminating the need for manually monitoring your site’s analytics.
• The /analytics/diskspace endpoint allows you to monitor disk space usage. This endpoint is particularly useful for monitoring how quickly disk space is filling up, such as when you have a team of content creators who can upload images and multimedia files, or when you allow your site’s visitors to upload images or files.

The /logs endpoint allows you to access your site’s raw data programmatically, providing valuable insights into various aspects of your site’s activity.

• You can use it to detect critical PHP errors in real time by filtering the error log for strings such as “PHP Fatal Error” or “Parse Error,” and sending an immediate notification to Slack or another messaging tool.
• You can also use the /logs endpoint to detect DDoS and login attacks. If you identify suspicious traffic patterns, you can automatically notify your developers to investigate immediately and/or automatically block the IP address from which the abnormal requests originate.
• Accessing server logs with the Kinsta API allows you to monitor 404 errors and set up automatic notifications for your IT team. This helps prevent SEO issues, check for errors after plugin or theme updates, identify slow scripts or plugins that generate excessive external calls, slow down TTFB, and much more.

With the Kinsta API, you can retrieve data related to your sites, environments, and domains.

You can also retrieve data related to plugins and themes, company users and activity logs, blocked IPs, backups, and much more.

3. Defining your script logic

The next step is to define the logic of your script. At this stage, you will use the data to generate meaningful notifications. Your script must check for abnormal behavior and determine whether it could compromise the site’s operation or security.

There are three main approaches to this phase:

Threshold-based logic: The simplest approach involves setting thresholds that, when reached, automatically generate a notification. For example, you could set a series of thresholds for resource consumption. Thresholds can also be set in relation to a time interval. For instance, you could set a threshold for daily server bandwidth consumption and generate a notification when it exceeds 10 GB. Below is an example of a request that provides server bandwidth consumption for the last 24 hours:

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/analytics/bandwidth?company_id={company_id}&time_span=24_hours' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

And here is the API response:

{
	"analytics": {
		"analytics_response": {
			"key": "bandwidth",
			"data": [
				{
					"name": "bandwidth",
					"total": 0,
					"dataset": [
						{
							"key": "2026-02-09T16:00:00.000Z",
							"value": "0"
						},
						{ ... },
						{ ... },
						{
							"key": "2026-02-10T15:00:00.000Z",
							"value": "0"
						}
					]
				}
			]
		}
	}
}

Relative or percentage change: Sometimes, an absolute number does not provide the necessary information, and analyzing relative or percentage changes may be more useful.

For instance, a sudden increase in 404 errors may indicate that a bot is scanning your site for sensitive files, such as .env or wp-config.php. However, the absolute number of 404 errors is not helpful. Using the /logs endpoint, you can retrieve the latest lines of the error log to analyze the frequency of errors and determine which files are being requested and from which IP addresses.

Below is an example of a request that provides the latest 1,000 lines of access logs:

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=access&lines=1000' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

If you want to dive deeper, we have a tutorial on how to retrieve server logs with the Kinsta API.

Sequential Failure Logic (SFL): The distinction between a professional system and a basic notification system is determined by the system’s ability to filter out noise and avoid false positives. For example, if the system sent a notification for every slow or unsuccessful API request, you would receive useless notifications and might ignore or miss important ones. A better approach is to instruct your script to notify you only if an error occurs after 3 consecutive checks.

Kinsta only sends monitoring notifications when our systems detect an error across 3 consecutive checks.

4. Connect to external tools

After confirming an anomaly requiring your attention, the next step is to distribute the information via your preferred communication or collaboration tools. Thanks to Kinsta’s RESTful API, you have maximum flexibility in choosing tools to integrate with your scripts.

Below are some examples of integrations:

• Instant communication: Slack or Microsoft Teams webhooks allow you to send notifications to specific channels.
• Critical notifications: When messaging systems aren’t enough, tools like Twilio or Telegram allow you to send messages directly to your team members’ smartphones.
• Push notifications: You can use Pushover or Pushbullet to send push notifications to mobile devices.
• Task management: If your team uses Jira, Trello, or Asana daily, your script can automatically generate and assign a card or ticket to your developers.

Integration and automation: The blueprint for forward-thinking agencies

For a forward-thinking agency, using Kinsta’s API to monitor your server environment and send automatic notifications is a strategic step. In today’s digital landscape, it’s not enough to simply be alerted when a site is down or underperforming. You need to build an intelligent infrastructure that drastically reduces Mean Time to Repair (MTTR) to ensure proactivity, scalability, and quality of service.

Kinsta provides more than just outstanding managed cloud hosting. Thanks to its open architecture, advanced management tools, and robust REST API, Kinsta allows you to integrate your hosting with the tools you use every day. This transforms maintenance from an operating cost into a smooth, automated process.

With this approach, you can stop reacting to emergencies and start orchestrating your customers’ success with the precision of an orchestra conductor. You can be confident that every component of your technology stack works together in perfect harmony.

Are you interested in learning more about Kinsta? Browse our plans, or reach out to our sales team.

The post How to set up custom MyKinsta notifications with the Kinsta API to catch issues before they impact users appeared first on Kinsta®.