User Guide

Everything you need to get PostRequest watching your PHP projects — from a one-line drop-in to reading AI diagnoses and wiring up the MCP server. This guide stays in step with the product documentation.

Overview

PostRequest is a lightweight monitoring system for PHP websites and web applications — drop a single file into your project and, from that moment on, every error is captured automatically, stored encrypted, and pulled into a central dashboard where you manage and analyse all of your projects in one place. No SaaS in the middle, no dependencies, no noise: it works quietly in the background and never changes how your application behaves.

It's built for developers and agencies who run more than one PHP site and want a single place to know when something breaks. Setup is one line of code; in return you get error tracking, health heartbeats, database-schema and DNS checks, a proactive risk engine, optional AI diagnosis, and an MCP endpoint your AI assistant can query — all self-hosted on your own server.

The most important features at a glance:

• One file, no dependencies — You include a single file, and that's it. No additional packages or extensions are required.
• One line to activate — After including the file, a single function call is all it takes to start monitoring.
• Zero impact on your application — PostRequest works entirely in the background. Your application behaves identically with and without PostRequest.
• Automatic encryption — All captured data is stored encrypted. Sensitive information (passwords, credentials, keys) is redacted automatically.
• Compatible with any system — PostRequest works with WordPress, TYPO3, Laravel, Symfony, Craft CMS, Drupal, Magento, Joomla and any custom application.
• CLI-capable — Also works in command-line scripts and cron jobs.

Getting Started

Requirements

• Server environment: PHP 5.6 or newer
• Recommended: the OpenSSL extension (present by default on most servers). Without OpenSSL no encryption is possible — PostRequest then works in plain-text mode.
• Web server: Apache or Nginx. On Apache, data protection is configured automatically via access rules. On Nginx, manual configuration is required (see Access Protection for Stored Data).
• Write permission: The web server needs write access to at least one directory so PostRequest can create its log files.

Integration

Copy the PostRequest file into your project and include it. Ideally this is done as early as possible in your application's loading process, so that errors occurring at start-up are captured too.

Examples for different systems:

Quick Start

After including the file, start PostRequest with a single call:

require_once 'PostRequestClient.php';

PostRequestClient::init([
    'servers' => [
        [
            'endpoint' => 'https://monitor.example.com',
            'secret'   => 'your-secret-key'
        ]
    ]
]);

That's it. From now on PostRequest automatically captures all errors in your application.

• The endpoint is the address of the monitoring server's dashboard — no additional path is appended. Depending on how the dashboard is installed this is the plain domain (https://monitor.example.com) or a subfolder (https://monitor.example.com/dashboard). You do not have to work this out yourself: the dashboard's Add Client dialog shows the ready-made snippet with the correct address already filled in. You will receive the exact address from your server administrator.
• The secret is a shared key that the server administrator creates for you and communicates once.

The dialog gives you the short form of the same call, which you can paste as it is:

PostRequestClient::init([
    'endpoint' => 'https://monitor.example.com',
    'secret'   => 'your-secret-key'
]);

Both notations are equivalent — use the servers list as soon as you want to connect to more than one monitoring server, or to set additional options alongside it.

Note: If you know an older version of this guide — the address no longer ends in /handshake. Use the plain dashboard address; a URL ending in /handshake does not lead anywhere on the server and the connection fails.

Configuration

Server Connection

Every server connection requires two mandatory values:

Note: The parameter is called endpoint. A server entry that uses a different key name (e.g. url) is ignored, and no connection is established.

Optional Settings

You can fine-tune the initialization with additional parameters:

Password-Protected Websites

If your website is protected by a server-side password (e.g. through an access-protection configuration of your web server), the monitoring server needs those credentials in order to reach the site — to retrieve error logs, perform heartbeats and make other requests. PostRequest transmits them during the handshake, but only when you ask it to. By default no credentials are collected, so a visitor's login details are never forwarded to the monitoring server unintentionally.

You have two options, both set with the top-level http_auth parameter:

Set the credentials yourself (recommended):

PostRequestClient::init([
    'servers'   => [['endpoint' => 'https://monitor.example.com', 'secret' => '...']],
    'http_auth' => ['user' => 'monitoring', 'pass' => 'the-password'],
]);

Or have them read from the current request:

PostRequestClient::init([
    'servers'      => [['endpoint' => 'https://monitor.example.com', 'secret' => '...']],
    'http_auth'    => 'auto',
    'endpoint_url' => 'https://your-domain.com/index.php', // required for 'auto'
]);

With 'auto', PostRequest picks up the credentials of the current request only when you have also specified endpoint_url yourself and the currently called address matches it exactly. This restriction is deliberate: it prevents the credentials of any visitor to any page from being collected.

Manually set credentials always take precedence.

Note: 'auto' only works in web operation. In CLI mode (e.g. cron jobs) no credentials are available — this has no effect on error capture.

Complete Configuration Overview

An example with the options described above:

PostRequestClient::init([
    'servers' => [
        [
            'endpoint' => 'https://monitor.example.com',
            'secret'   => 'your-secret-key'
        ]
    ],
    'project_name' => 'My Web Shop',
    'environment'  => 'production',
    'tags'         => ['wordpress', 'live'],
    'max_log_size' => 52428800,
    'max_file_size' => 10485760,
    'dedup_ttl_days' => 7,
]);

Beyond these there are further expert settings (among them http_auth, endpoint_url, client_id, data_dir, web_root and the redaction lists). They are only needed in special setups and are described in the technical documentation.

How It Works

Handshake (Initial Connection)

On its first start, PostRequest performs a one-time connection with each configured server:

1. PostRequest sends a request to the monitoring server with your secret and a freshly generated key pair. If the website is password-protected, the credentials are sent along automatically (see Password-Protected Websites).
2. The server verifies the secret and responds with its own key.
3. From this point on, server and client can communicate in encrypted form.

This process happens once and automatically. If the handshake fails (e.g. because the server is unreachable), your application continues to work undisturbed. PostRequest does not retry the handshake automatically — but you can trigger it manually (see Restoring a Server Connection).

The handshake has a time limit of 10 seconds. If the server does not respond within that time, the attempt is aborted.

Error Capture

After initialization, PostRequest automatically captures:

• All runtime errors (warnings, notices, fatal errors)
• Uncaught exceptions
• Suppressed errors (calls suppressed with @ are logged as well, but the suppression in your application remains in place)
• Fatal errors that cause the script to terminate

For each error, extensive context information is stored:

• Timestamp, error message, file and line
• The requested URL and request method
• Request parameters, browser identifier, IP address
• A full call stack (trace)
• Information about the most recent page visits (ring buffer)

Important: PostRequest does not interfere with your existing error handling. If your application already uses its own error-handling routines, they continue to run as usual. PostRequest inserts itself into the existing chain.

Duplicate Detection

PostRequest detects identical errors automatically — even across multiple page visits. If the same error occurs repeatedly (e.g. on different pages or for different visitors), it is stored only once and given a counter that indicates how often it has occurred in total.

The monitoring server additionally aggregates the entries and shows a breakdown by user and environment. This keeps you informed without being flooded by hundreds of identical error messages.

The duplicate-detection state is kept for 7 days by default. After this period, a previously known error is captured again as a new entry when it recurs. You can adjust this retention period via the dedup_ttl_days setting (see Configuration). The server can also set this value centrally — but a locally set value always takes precedence.

Server Communication

After the handshake, PostRequest is passive — it no longer contacts the server on its own. Instead, the monitoring server requests information when needed:

• Retrieve error logs — The server collects the gathered error messages. After a successful transfer, the local logs are deleted.
• Heartbeat (status check) — The server queries the state of the system: installed extensions, disk space, detected frameworks, validity of the security certificate and more.
• File list (sitemap) — The server can request an overview of all files in the project directory.
• File transfer — The server can request individual or multiple files (e.g. for code analysis).
• Database structure — The server can query the structure of the database (tables, columns, relationships). Actual data is never transmitted.

All of these requests are encrypted and signed. Invalid or tampered requests are rejected.

Dashboard

The PostRequest dashboard is the central interface for managing all monitored projects. Here you see all connected clients at a glance, and you can retrieve error logs, check system states, view files and manage users.

Deploying the Dashboard

There are two ways to deploy the dashboard on your web server:

Option 1 — Dashboard directory as the web root (recommended for dedicated installations): Configure your web server to point directly at the dashboard directory. In this case, the dashboard is the only application reachable through the browser, and it appears directly under your main address (https://your-domain.com/).

Option 2 — Project directory as the web root: You can also use the entire project directory as the web root. In this case, the dashboard appears directly under your main address (https://your-domain.com/) — so you see it immediately, without any redirect. It additionally remains reachable under https://your-domain.com/dashboard/. (Previously the main address redirected to the sub-address /dashboard/; now the dashboard is shown directly at the main address with no detour.) Requests over an unencrypted connection (HTTP) are automatically redirected to the encrypted address (HTTPS) — so you and your visitors always end up on the secure connection. The connection between the monitored projects and the server (handshake) continues to work smoothly, because those requests are processed internally without a redirect. All other files and directories in the project are protected on multiple levels — both at the level of the main directory and through their own access rules in each individual subdirectory. Direct access to source code, documentation or other project files through the browser is not possible. This protection works automatically on Apache web servers and requires no additional configuration.

Operation in a subfolder: You can also run the dashboard in a subfolder of your domain, e.g. under https://your-domain.com/monitoring/. This is supported too — the dashboard adapts automatically to the address under which it is accessed.

In all cases the dashboard works fully: Whether the dashboard is located directly under your main address, under /dashboard/ or in a subfolder — the presentation loads correctly (layout and buttons appear as intended), navigation and all internal links lead to the right place, the setup wizard runs through without errors, and the “Manage subscriptions” link in the digest emails always opens the correct page. You don't need to configure anything extra for any of these deployment options.

Note for Nginx users: The automatic access protection and the automatic serving of the dashboard at the main address only work on Apache web servers. If you use Nginx and want to use Option 2, you must set up both the serving of the dashboard at the main address and the blocking of access to all directories except dashboard/ manually in your web server configuration. Contact your server administrator for the exact setup.

Initial Setup

When you open the dashboard in your browser for the first time, you are automatically guided through a setup wizard. This replaces the earlier single first-run page and takes you in four steps from an empty installation to a ready-to-use dashboard. At the top of the wizard you can always see where you are (e.g. “Setup · Step 2 of 4”).

You don't need to prepare the server for this. The wizard checks the environment, creates all required directories and keys itself, lets you create your administrator account, and finally provides guidance for ongoing operation. Once setup is complete, the wizard does not reappear — every further visit takes you straight to sign-in. For an already configured installation, the wizard is skipped entirely.

Step 1: Environment Check

The wizard first checks whether the server can run PostRequest. This check is read-only — nothing is changed. Each item receives a coloured label:

Mandatory requirements (red if not met) include a sufficiently recent PHP version, the OpenSSL and JSON functions, and a writable data directory. Non-critical notes (yellow) include a missing HTTPS connection, an unavailable email dispatch and a not-yet-configured background service (cron). For each flagged item, a short hint explains what to do.

• Fix the red items on the server and then click Re-check to repeat the check.
• Once all mandatory items are met, click Continue to move to the next step.

Step 2: Storage

In this step the wizard automatically creates everything PostRequest needs in order to work — including the data directory (with access protection), the internal security keys and the default settings. You don't need to enter anything.

For each entry it shows whether it was newly created (Created, green) or already existed (Already present). Existing items are left unchanged.

• Click Continue to proceed.
• If the data directory is not writable, the wizard shows a hint with the affected path. Grant the web server the necessary write permissions and click Re-check.

Step 3: Administrator Account

Here you create the account you will use to sign in to the dashboard in future:

1. Enter your email address in the “Email Address” field.
2. Choose a password (at least 8 characters) and enter it in the “Password” field.
3. Confirm your password in the “Confirm Password” field.
4. Click Create Account.

After the account is created you are signed in automatically and reach the final step.

Step 4: Completion

At the end, the wizard points out two things it cannot do for you. You can take care of these at any time:

1. Background service (cron): Background refresh and the sending of digest emails run via a cron job. The wizard shows the matching entry, which you add to your scheduler (crontab) to run every minute. Details can be found under Cron Jobs.
2. Email dispatch: For the verification codes of two-factor sign-in and for the digest emails, email dispatch must work. Using the Send test email button you can send a test message to your administrator address and thus check whether dispatch works. A confirmation indicates whether the email was sent — check your spam folder too if necessary.

Finally, click Finish & go to dashboard. This completes the setup. You are not, however, signed in immediately: so that email dispatch is verified right away the first time, the wizard ends your session and shows the two-factor confirmation directly. A fresh verification code is sent automatically to your administrator address. Enter this code (see Two-Factor Authentication) to reach the client overview. This immediately confirms that the verification codes actually arrive.

Signing In

To sign in to the dashboard:

1. Enter your email address in the “Email Address” field.
2. Enter your password in the “Password” field.
3. Optional: enable “Remember this device for 30 days” to stay signed in on this device for 30 days.
4. Click Sign In.

Protection against brute-force attacks: After several failed sign-in attempts, sign-in is temporarily locked. A message tells you how many minutes you have to wait before another attempt is possible.

Forgotten password: Below the sign-in form you'll find the Forgot your password? link. It leads to a page where you enter your email address; a link to reset the password is then sent to that address. For security reasons you always receive the same generic confirmation (“If an account exists for this address …”), regardless of whether the address is actually registered. The reset link is valid for 1 hour and can be used only once.

Two-Factor Authentication

After a successful password entry, the dashboard asks for a second factor: a 6-digit code that only you can supply. There are two ways to obtain this code, and each account uses exactly one of them:

• By email (default): A fresh 6-digit code is sent to your email address every time you sign in. Your email address is shown partially masked (e.g. d***example.com).
• From an authenticator app: If you have set up an authenticator app for your account (see Using an Authenticator App), the code is generated on your phone instead. In this case no email is sent — the confirmation page then reads “Enter the 6-digit code from your authenticator app”.

Entering the code (both methods):

1. Get the current 6-digit code — from the email message, or from your authenticator app.
2. Enter the 6-digit code in the “Verification Code” field.
3. Click Verify.

If you use email codes and the code did not arrive:

• Click Resend code to request a new code.
• Click Back to login to return to sign-in and try again.

Note: The Resend code button appears only for email codes. With an authenticator app there is nothing to resend — the app always shows a fresh code by itself.

The same second factor is also requested on the authorisation screen that appears when you connect an external application to your account: an account with an active authenticator app enters the code from the app there too, and no email code is sent.

Using an Authenticator App

Instead of waiting for an emailed code at every sign-in, you can have the code generated by an authenticator app on your phone — for example Google Authenticator, Authy or 1Password (any standard authenticator app works). The code then appears in the app and refreshes automatically every few seconds. This is quicker to enter and keeps working even if you cannot reach your email.

Setting it up (only you can do this for your own account):

1. Open your own user settings (on the “Users” page, click Settings in your row).
2. In the Two-Factor Authentication section, click Set up authenticator app.
3. Install an authenticator app on your phone if you don't have one yet.
4. Scan the QR code shown on screen with the app. Can't scan it? The screen also shows a secret in text form that you can type into the app manually.
5. The app now shows a 6-digit code. Enter it in the Code from the app field and click Activate.

From then on, your login codes come from the app and no email code is sent — for both the normal dashboard sign-in and the authorisation screen for external applications.

One-time reminder after sign-in: If your account still uses email codes, the dashboard shows a one-time prompt after signing in (from your second sign-in onward) that invites you to set up an authenticator app. You can either follow it straight away or click Set up later. Once you dismiss it with Set up later — or actually set the app up — it does not appear again.

A used code cannot be reused: For security, each code works only once. If you accidentally enter a code the app has already shown and used, you'll see the message “That code was already used. Wait for your authenticator app to show the next one, then enter it.” Simply wait for the app to display the next code and enter that.

Switching back to email codes (deactivation): In the Two-Factor Authentication section of the user settings, a Deactivate authenticator button removes the app again; the account then receives its login codes by email as before. Deactivation is also the recovery path when someone has lost their phone: any user can deactivate another user's authenticator (setting up an app, by contrast, only the account owner can do). See Authenticator App Not Working or Phone Lost.

Note: Resetting your password (via the Forgot your password? link) only proves that you own the email address — it does not switch off an active authenticator app. After a password reset you therefore still need the app to sign in. If you have lost both your password and the phone with the app, a colleague must deactivate your authenticator for you; you can then reset your password and sign in with an email code.

If a Code Has Never Arrived (Lockout Protection)

So that the installer (the first administrator account created during setup) does not lock themselves out of the dashboard if email dispatch does not yet work on a newly configured server, there is a one-time exception:

• As long as a verification code delivered by email has never been successfully entered on this server, an additional E-mail not received? button appears for the installer account on the confirmation page.
• Click it to sign in without a code. This emergency access serves solely to fix a problem with email dispatch. This way the device is not remembered for 30 days — you'll have to sign in again next time.
• All other users must always enter the verification code; this exception is not available to them — not even if dispatch has not yet been confirmed.
• Once the installer has successfully entered a real, email-delivered code once, email dispatch counts as confirmed: the E-mail not received? button disappears permanently, and from then on a code is mandatory at every sign-in.

Note: During this transition period — before the installer has confirmed a real code for the first time — the dashboard is effectively protected only by the password for the installer account. This is a deliberate choice to prevent a lockout, and it ends automatically as soon as email dispatch demonstrably works. Therefore, fix the email problem promptly.

Help hint after emergency sign-in: After signing in via E-mail not received?, a one-time hint window titled Didn't get your verification code? appears. It names the two most common causes:

1. Email dispatch is not working — For verification codes and digest emails, the server must be able to send emails. Check whether your server actually sends emails and whether the background service (cron) runs every minute (see Cron Jobs).
2. The stored email address is wrong — The codes are sent to the email address of your account. If it is wrong, correct it via the Fix account email button, which takes you directly to the user settings (see User Settings).

Close the window via Got it or the ×. The hint is shown only this one time.

Interface Layout

After signing in, you see the dashboard interface with the following elements:

• Sidebar (left): The navigation with five main areas:
  • Clients — Overview of all connected projects
  • Errors — Error overview across all clients
  • Compare — Comparison of two clients
  • Users — User management
  • Settings — Server settings
• Header (top): Shows your signed-in email address and the Logout button to sign out.
• Content area: The central area that shows different information depending on the selected menu item.

Count badges in the navigation: Small numbers (bubbles) can appear on the Errors and Clients menu items, showing the overall state across all projects at a glance:

• On the Errors menu item, a red badge shows the total number of counted errors across all clients. Only the error types that are counted according to the “Counted Error Types” setting are taken into account, and only the configured error period (see Server Settings). Hidden (solved) errors are not counted (see Hiding and Re-showing Errors).
• On the Clients menu item, a yellow badge shows the number of clients that are not healthy (e.g. unreachable or with errors).

If there is nothing to report (no counted errors or no problematic clients), the respective badge is hidden. The badges are updated whenever a list is refreshed — for instance after a manual refresh or an automatic update.

On small screens you can show and hide the sidebar via the menu icon (☰) in the header.

Client Overview

The client overview is the start page of the dashboard. It shows all projects that have connected to this monitoring server.

Table: Each client is shown in a row with the following information:

If no heartbeat data is available yet for a client, the columns PHP, Errors, SSL, Heartbeat and Last Error show a dash (—).

Display and layout: The table is designed to fit the available width, so you never have to scroll it left and right. Longer values stay readable rather than breaking the layout: a long server hostname is shortened with an ellipsis (…) — hover over it to see the full value — and error-type badges, PHP versions and the column headings each stay on a single line. The heading of the notification column (Update) is centred over its bell icon.

Filter bar: Above the table you can narrow down the list:

• Search — Enter a domain name, a project name or part of one to filter the list.
• Environment, tags and frameworks — A combined dropdown for narrowing the list by environment, by tag or by detected system/framework. Environments, tags and frameworks are offered as three separate groups within the same dropdown, and each group appears only when there are actually values to choose from. Choose one entry to show only the clients that match it. In the Frameworks group, clients without a detected framework are grouped under Other; the group appears only when there are at least two framework groups to choose from — that is, at least two different detected frameworks, or at least one detected framework alongside clients that have none. If every client runs the same framework (or none is detected at all), the group is hidden, since a choice would be pointless. The framework is not shown as its own column. The reset entry at the top clears the filter again; it is labelled All Tags whenever tags or a selectable framework group are available, and All Environments when only environments are present. If there is nothing to filter by at all, the dropdown is hidden entirely.
• Status — Narrows the list by the client's status. The options are offered in two groups: under Health you filter by the current overall state — Healthy, Issues or Unreachable — and under Client by whether the monitoring client embedded in the project is up to date with the version offered by this server: Outdated library shows clients running an older version, Current library those already up to date. The All Statuses entry at the top clears the filter again.

Click a row in the table to open the client's detail view.

Adding a Client

To connect a new project, click + Add Client above the client list. An overlay opens that gives you everything needed to integrate the monitoring client into your project. It guides you through three steps.

Step 1 — Add to your project: Here you find the client to place in your project, always shown as real, paste-ready code. Two buttons control how you take it:

• Download saves the complete client library as the file PostRequestClient.php, to place next to your bootstrap file.
• Separate library / Combine library switches the setup snippet between two variants:
  • By default the snippet is combined — a single, self-contained block that already contains the complete client together with the start call, so you can paste everything in one place without shipping a separate file.
  • Click Separate library to keep the client in its own file instead. The library then appears in its own box, and the snippet switches to the shorter require_once variant that loads PostRequestClient.php from that box. The button now reads Combine library, with which you can inline it again.

Each code box has its own Copy button, so you can copy either the client library or the setup snippet with one click.

Server Secret: Below the snippet, the shared secret for this server is shown with its own Copy button. It is already contained in the setup snippet — you only need it separately if you configure the connection by hand.

Step 2 — Register the client: Open any public URL of your project once. This triggers the one-time handshake with the server (see Handshake).

Step 3 — Verify: Refresh your client list. The new client should now appear. If it shows up without data, open its settings and make sure the address it registered with is publicly reachable; if it does not appear at all, the handshake did not succeed.

You close the overlay via the × at the top right.

Automatic Refresh

Each client is updated individually and automatically — based on the refresh interval set for it individually (see “Actions” Tab). When you open the client overview, the dashboard checks for each client whether the configured interval has elapsed since the last update. Only clients where this is the case are updated.

While a client is being updated, a small loading icon appears in its row in place of the status dot. Updating happens sequentially — one client after another. You can continue using the dashboard as usual during this time.

Manual Refresh

Click Refresh to update the data of all clients immediately — regardless of when the last automatic update took place. Here too the loading icon appears in the row of the client currently being updated.

Digest Notifications

In the last column of each row there is a bell icon (🔔) with which you can control the digest notification for the respective client.

How the toggle works: Click the bell icon to cycle between the three states:

Each click advances to the next state: None → Daily → Weekly → None. The change is saved immediately — a notification confirms the new setting. Hover over the icon to see the current state.

You set the default for the digest per user on the “Users” page (see User Settings). The toggle via the bell icon overrides this default for the individual client.

Client Detail View

The detail view shows all available information for a single client. Via the “← Back to clients” link you return to the overview.

Page title: Before the title, a coloured status dot is shown — green when the client is reachable and error-free, red when there are errors, the client is unreachable or the last heartbeat is too long ago. If a project name is set, it is used as the page title. Otherwise the domain is shown (without a leading “www.”).

Directly below the title there is a metadata bar with the most important key facts at a glance:

Below the metadata bar, the remaining information is divided into six tabs. The “Heartbeat” tab is selected by default.

“Heartbeat” Tab

The heartbeat provides a snapshot of the system state of the monitored project. The information is organised into seven sub-tabs so you can quickly navigate to the area you want.

Click Trigger Heartbeat to retrieve current system information from the client. The sub-tabs appear below the button and are arranged horizontally. On small screens you can scroll the bar sideways to reach all entries.

The reported settings reflect the application's live configuration: the values that appear here (such as timezone, error reporting and PHP limits) are captured during normal visitor requests, after your application has applied its own settings. So they show the configuration your application actually runs with, not the values a bare server request would see.

Sub-tabs at a Glance

The “Overview” sub-tab is selected by default when the heartbeat is opened.

Overview — Analysis Cards

The “Overview” sub-tab shows a set of cards in a grid. Each card summarises a specific area of the system state and shows coloured hint markers where needed.

Status — Shows the installed PHP version as the main value. In addition it lists operating system, hostname, server software, uptime, timezone and server time. If a hosting control panel is detected, a “Panel” entry is shown as well.

• Hint marker “EOL” (red): The PHP version is no longer supported.
• Hint marker “Security only” (yellow): The PHP version only receives security updates.

Security — Assesses the security configuration of the server. The main marker shows the status of the security certificate.

• “Valid” (green): certificate valid, more than 30 days remaining.
• Number of remaining days (yellow): fewer than 30 days until expiry.
• Number of remaining days (red): fewer than 7 days until expiry.
• “Expired” (red): certificate expired.

Individual security settings are additionally checked and flagged with warning markers where noteworthy (e.g. when error display in the browser is enabled or no function restrictions are configured).

Disk — Shows the available and total disk space. Below it is a bar chart that visualises disk usage:

• Green: normal usage (below 80 %).
• Yellow: elevated usage (80–95 %).
• Red: critical usage (above 95 %).

In addition, the size of the log folder, the number of log files and the document root are shown.

PHP — Shows the most important PHP configuration values: memory limit, maximum execution time, upload limit, request size limit, PHP server interface (SAPI), the error reporting level (shown as readable labels rather than a technical number), whether error logging is active, and the number of loaded extensions. A marker shows whether the cache (OPcache) is active. Clicking the card jumps to the “PHP” sub-tab.

DNS — Shows the domain name records for the monitored project's address. This card is loaded on demand and can be opened for the full details.

Application — Shows the detected system or framework (e.g. “WordPress” or “Laravel”) together with its version if available; if no framework is detected but version control is present, the active branch is shown as the main value instead. Below it are the project, environment and tags, along with the latest commit. The Project, Environment and Tags shown here come from the client record — that is, the values the client reported when connecting, or the values you overrode in the “Actions” Tab. (In earlier versions these could appear empty; they are now taken reliably from the client record.)

Framework detection runs entirely on the server, based on the client's file list only. A version number is shown only when one or more optional version sources are configured for the framework (defaults ship for WordPress, Laravel, Symfony and Drupal). Presence of a framework is re-checked cheaply on every heartbeat; the version is only read when the file list (sitemap) is refreshed. See Server Settings for how to edit the detection rules.

Recent Requests — Shows the most recently captured page visits (up to the last 10) with the request time, method, URL and status. Requests in which errors occurred are highlighted accordingly. If no request data is available, a corresponding note is shown.

Client — Shows technical key facts of the client: endpoint address, client ID, version and connected servers. Next to the version, a coloured label is shown: “Current” (green) when the client uses the current version, or “Outdated” (yellow) when a newer version is available. This check uses the version identifier embedded in the client, not the entire file. As a result, the client is still correctly recognised as “Current” even when it is embedded together with other code in one file — an incorrect display as “Outdated” no longer occurs in this case.

History and Change Comparison

A new entry in the heartbeat history is stored only when something has actually changed in the environment or configuration — e.g. a new PHP version, changed extensions, adjusted settings or a renewed security certificate. If everything remains unchanged, no additional entry is created. As a result, the history shows only relevant changes and stays clear.

Version display: Next to the “Heartbeat” heading, a version indicator appears as soon as more than one entry exists. It shows “Current (N of N)” when you are viewing the current state, or “Previous (X of N)” for older entries. This way you always see which state you are currently looking at.

Navigation: To the right of the entry's age are the navigation buttons “← Prev”, “Next →” and “Current”. These are shown only when multiple entries exist. With “Current” you jump straight back to the current state.

Change comparison (diff mode): When you open an older entry, the differences from the current state are highlighted:

In the “Overview” sub-tab, cards that contain changes get a coloured side border (yellow) so you can tell at a glance which areas have changed. Cards without changes are automatically shown semi-transparent so the relevant areas stand out clearly.

“Show all information”: When you view an older entry, a “Show all information” checkbox appears next to the version indicator. Enable it to show unchanged cards at full visibility too. This lets you inspect the full system state of the older entry when needed, without unchanged areas being greyed out.

Display on Small Screens

On mobile devices and narrow screens, the view adapts automatically:

• The sub-tabs are shown in a horizontal bar that can be scrolled sideways.
• The analysis cards in the “Overview” sub-tab are shown stacked instead of side by side and take the full width.

“Errors” Tab

Here you can retrieve and view the client's error logs. The tab shows all captured errors regardless of the configured error period. Only the error count in the overview and the status display depends on the configured period (see Error Period).

1. Click Retrieve Logs to retrieve the current error messages from the client.
2. The errors are shown in a table with the following columns:

Colour coding by severity: The severity label (“Level”) is coloured according to its urgency. The same colours are used everywhere a severity is shown — in this error list, in the error detail view and in the most recent errors:

Filtering: Above the table there are two dropdown menus with which you can narrow the display:

• All Levels — restricts the display to a specific severity (e.g. Error, Warning, Notice, Fatal).
• All PHP versions — restricts the display to errors that occurred under a specific PHP version.

Both menus are data-driven: they list only the values that actually occur in the retrieved errors. If there are fewer than two distinct values, the respective menu is hidden automatically — a choice would be pointless anyway.

Aggregated errors: Identical errors are automatically combined into a single entry. The “#” column shows how often the error occurred in total. The “Last Seen” and “First Seen” columns indicate the period in which the error was observed. Both timestamps are shown in the format DD.MM.YYYY HH:MM:SS.

Hiding and Re-showing Errors

Errors you have already reviewed or fixed can be hidden from the list (“solved”) so that only the relevant, open errors remain visible. This function is available both in this list and in the Error Overview (All Clients).

• Hide (solve): At the end of each error row there is a × button. Clicking it marks the error as solved and hides it from the list.
• Re-show: Via the ✓ (checkmark) button in the row of a solved error, you bring it back into the list. Hover over the button to see who hid the error and how often it has already been hidden and reappeared.
• “Show solved”: As soon as at least one error is hidden, a Show solved switch appears above the table, with which you can additionally show the solved errors.

Effect on counts: Hidden errors are removed from all counts — from the error count, from the tab's Errors badge, from the count badges in the navigation (see Interface Layout) and from the detection of unhealthy clients. A client whose only errors are hidden thus counts as error-free again.

Automatic reappearance: A hidden error automatically reappears in the list as soon as it recurs (a newer occurrence is captured). From then on it is counted again. You can additionally be notified by email about the reappearance (see Health Digest).

The information about which errors are hidden is stored encrypted per client. The full history is recorded (hidden, reappeared, re-shown) — each time with the acting user and the time.

Error detail view: Click an error row to open a detail view as an overlay. The overlay shows detailed information about the selected error and is divided into six tabs:

Fields for which no information is available are automatically hidden in the detail view — only relevant data is shown.

Data from the time of the error: All details shown in the detail view — PHP version, memory values, settings, server and environment data, the list of included files, etc. — were captured at the moment the error occurred. They therefore reflect the state at that time, not necessarily the current one. The only exception is the content of files you open via preview or download: here the current version of the file on the server is always shown (see the note about possibly changed files below).

You can close the overlay via the × button at the top right, the Escape key or by clicking the dimmed background.

Viewing and downloading files: For many errors the associated source files are available — both the files included at the time of the error (in the “Server” tab under the heading “Included Files”) and the files from the call trace (in the “Stack Trace” tab under the heading “Stack trace files”). In both lists, next to each file there is a Preview button for viewing and a Download button for downloading.

• Preview opens the file directly in the integrated preview, without leaving the overlay. The line relevant to the error is highlighted and automatically scrolled into view.
• In the “Stack trace files” list, a marker (e.g. #0, #1) additionally shows at which level of the call trace the respective file first appears.
• The files named in the displayed call trace itself are also clickable — a click opens the preview directly at the matching line.
• In the header of the overlay you'll also find a Preview button with which you can view the error's main file.

Download multiple files bundled together: Via the Download All as Archive button (for the included files in the “Server” tab) or Download Files in the header of the overlay (for the files of the call trace), you download all associated files together as an archive. The folder structure within the archive matches the structure on the server, so the files are easy to place. Internal program steps without an associated file are not included in the archive.

File paths: All paths are shown relative to the web root — that is, the same way as in the sitemap. Files located outside the web directory can, for security reasons, neither be viewed nor downloaded.

Note — file may have changed: Preview and download always show the current version of the file on the server. If a file has changed since the error occurred (recognisable by a file size that differs from the one originally captured), the note “This file may have changed since the error.” appears. The displayed content may then differ from the one that was actually executed at the time of the error.

“Requests” Tab

Shows the client's most recently captured page visits (requests) in a table with the columns Time, Method, URL, Status, IP, Agent (browser identifier) and Errors. Click Refresh to update the display from the latest heartbeat.

Errors column: For requests in which errors occurred, the “Errors” column shows a separate coloured label per error type that occurred — in the same colours as the error list (see “Colour coding by severity”). The labels are sorted by severity so the most urgent errors appear first. If an error type occurred multiple times, the count is shown on hover. Requests without errors show a dash (—).

Badge on the tab: On the “Requests” tab a small number (badge) appears, indicating how many of the most recently captured requests triggered a counted error. Only error types that are actually counted for warnings according to the “Counted Error Types” setting in the Server Settings are taken into account — error types deselected there leave the badge unaffected.

“Sitemap” Tab

Shows the file structure of the monitored project as an expandable folder tree.

1. Optional: In the “Extensions” field, enter file types to filter by (e.g. php,html).
2. Optional: In the “Subdirectory” field, enter a subdirectory to show only its content.
3. Click Load to retrieve the file list.

The results are shown as a folder tree in a table with the columns Name, Size and Modified date. Before each entry, an icon indicates the file type — folders, script files, stylesheets, images and other common formats each get their own icon. Subfolders are clearly set off from the parent level by indentation and visual markers, so the nesting is recognisable at a glance. The modified date is shown in the format DD.MM.YYYY; for recently changed files a relative indication appears instead (e.g. “2 hours ago”).

Folders can be expanded and collapsed by clicking the entire row.

Downloading: Next to each file there is a download button with which the file can be downloaded directly. Non-previewable files (e.g. PDF, ZIP, font files) are downloaded automatically on click, while text files open in a preview. Binary files such as images, fonts and PDFs can also be downloaded. For folders there are two options: all files of the folder as a ZIP archive, or only the script files as a ZIP archive. Above the table are the Download All (all files of the project) and Download Scripts (only script files) buttons.

Preview: Clicking a file row opens the preview directly in the browser. Text files and images are shown as an overlay over the current page. For text files, line numbers are shown and a search function is available. Images are displayed at an adjusted size. Empty files show the note “File is empty” instead of an empty preview. The preview can be closed via the X button, the Escape key or a click on the background. If no preview is available for a file type, a download is offered instead.

Note: Sensitive information in configuration files is redacted automatically before transmission (see Data Redaction).

Versioning: When files in the project change, a new version of the file list is created automatically on the next query. Older versions are retained and can be accessed via the version navigation. The display shows “Current sitemap (N versions)” when you are viewing the current version, or “Version X of N” for older versions. As long as no files have changed, no additional version is created on reload.

Switch view: In the top right of the sitemap there is a switch with which you can toggle between two views:

• Tree view — shows the file structure as an expandable folder tree (default view).
• Recently changed — shows all files sorted by modified date, newest first. The list contains up to 100 files per page. Folder path and file name are shown separately in each row and are independently clickable.

Search: Above the tree or list there is a search field. The search takes effect immediately as you type and searches the full path of each file (substring search). If the search term begins with /, the search is restricted to files in the specified directory — /includes, for example, shows only files directly under /includes/. The X at the right of the search field clears the input.

Back to the folder tree: Clicking the folder path of a row in the “Recently changed” view switches back to the tree view and opens the relevant folder directly.

“Database” Tab

Shows the structure of the monitored project's database — tables, columns and their relationships only. Actual data is never transmitted.

Note: This tab was previously called “DB Schema” and has been renamed to “Database”.

Connection Settings

To retrieve the database structure, you first need to enter the connection details. Click the gear icon (⚙) to the right of the heading to show or hide the connection fields.

1. In the Driver dropdown, choose the database type (MySQL, PostgreSQL or SQLite).
2. Enter the connection details:
   • Host — The address of the database server (e.g. localhost)
   • Port — The port of the database server (e.g. 3306 for MySQL, 5432 for PostgreSQL). If no port is entered, the default port of the chosen driver is used automatically (3306 for MySQL, 5432 for PostgreSQL).
   • Database — The name of the database
   • User — The user name for the database connection
   • Password — The password for the database connection
3. Remember password — Enable this option if the password should be stored together with the connection. If the option is disabled, the password is not stored and must be entered again each time it is used.
4. Click Fetch Schema to retrieve the database structure.

Saved Connections

You can save connection details in order to reuse them quickly later.

• Save a connection: Fill in the connection fields and click Save. The connection is saved automatically with a name in the format “Host / Database name”.
• Load a connection: Once saved connections exist, a dropdown appears next to the heading. Choose a connection, and the fields are filled in automatically. Then click Refresh Schema to retrieve the structure.
• Delete a connection: Choose a saved connection in the dropdown. A × button appears next to the dropdown. Click it to remove the connection after confirmation.

Up to 10 connections can be stored per client.

Structure Display and Summary

After the retrieval, the database structure is shown. At the top there is a summary bar with the most important key figures:

Each table is shown as an expandable card. Click a table to show its columns, indexes and foreign keys.

• Expand All — Expands all tables at once.
• Collapse All — Collapses all tables at once.

Version History

As with heartbeat and sitemap, a new entry is stored only when the database structure has actually changed — e.g. new tables, changed columns or removed relationships. If the structure remains unchanged, no additional entry is created.

• The display shows “Current” with “(N of N)” when you are viewing the current structure.
• For older versions, “Previous” with “(X of N)” is shown.
• Use the ← Prev, Next → and Current buttons to navigate between versions.

“Actions” Tab

Contains management actions and settings for the selected client. The tab is divided into several sections, each with its own heading and explanation.

Identity

In this section you can override, on the server side, the identity fields transmitted by the client. This is useful if you want to correct the environment or project name centrally, for example, without changing the configuration on the website itself.

How the settings hierarchy works: Each client transmits its own values for environment, project name and tags when connecting. Below each field, this value sent by the client is shown as a reference (e.g. “Client value: production”). When you fill in a field in the dashboard, your value is used as a server-side override and takes precedence over the client value. When you leave a field empty, the value sent by the client applies.

Changes are saved automatically as soon as you leave a field or press Enter.

Endpoint Settings

This section shows the address under which the dashboard contacts this client, as well as the status of HTTP authentication. By default, the address the client transmitted when connecting is used.

The overview shows:

Click Change to edit the settings in an overlay.

“Edit Endpoint” overlay:

• Endpoint URL — Enter a different address to override the one registered by the client. Leave the field empty to use the client-registered address.
• HTTP Auth Username / HTTP Auth Password — Store the credentials here if the website is protected by a password prompt (HTTP basic auth). The password field shows “•••••• (unchanged)” when credentials are already stored — leave it empty to keep the stored credentials.
• Save — On the first click, the dashboard checks the reachability of the given address. If the connection succeeds, the settings are saved. If the test fails, an error message appears along with the Save anyway button, with which you can save regardless.
• Clear Auth — Removes the stored HTTP credentials. Afterwards only the address without authentication is contacted.
• Cancel — Closes the overlay without saving changes.

Note: If the client sends new credentials the next time it connects, these are adopted automatically and replace the values set in the dashboard.

Automatic Refresh (Auto Refresh)

Here you can set an interval in minutes at which the data of the currently open tab is refreshed automatically. Automatic refresh is supported for the Heartbeat, Errors, Sitemap and Database tabs.

When the function is active, a “Auto-refresh: every X min” note appears next to the tabs. Leave the field empty to disable automatic refresh. Changes are saved automatically.

Notification Recipients

This section shows which people receive the Health Digest for this client, and lets you adjust the delivery.

Dashboard users: All users created in the system are listed automatically. Next to each user you see their current digest frequency for this client. Via a selection field you can change the frequency per user:

The change is saved immediately.

Add your own email addresses: Below the user list, you can add additional email addresses that should also receive notifications — e.g. for external recipients who don't have a dashboard account.

1. Enter the email address in the input field.
2. Choose the desired digest frequency in the dropdown next to it (Daily, Weekly or None).
3. Click Add.

The added addresses appear in a table with the columns “Email”, “Digest Frequency” and a remove button. The frequency can be changed at any time via the dropdown in the table. Changes are saved immediately. The address can be removed again at any time by clicking the remove button.

Note: An email address that is already assigned to a dashboard user cannot be added as your own address. In this case, use the selection field next to the user to change the frequency.

Send digest immediately: With the Send digest now button you can send a one-time Health Digest for this client immediately — regardless of the configured frequencies. The digest is sent to all dashboard users and your own email addresses listed in this section.

Key Rotation

This action renews the encryption keys for the client. Error logs not yet retrieved are automatically backed up beforehand.

1. Click Rotate Keys.
2. A confirmation dialog appears. Read the note carefully — this process cannot be undone.
3. Click Rotate Keys in the dialog to confirm the rotation, or Cancel to abort.

Error Overview (All Clients)

The Errors area in the sidebar (between Clients and Compare) gathers the stored errors of all monitored clients into a single list. This way you can see at a glance where errors occur across the entire estate, without having to open each client individually.

Table: The errors are listed with the newest first. The columns largely match those in the “Errors” tab of the client detail view, supplemented by a Client column that shows which project the respective error belongs to:

Filtering: Above the table there is a filter bar. The client search and the severity and PHP filters share the row evenly — depending on how many filters are currently visible, they take the full width or share it in equal parts.

• Search clients — Enter a client name or part of one to restrict the list to specific projects.
• All Levels — Restricts the display to a specific severity. The severities are grouped by urgency (Critical, Fatal, Warning, Notice); you can select a whole group.
• All PHP versions — Restricts the display to errors that occurred under a specific PHP version.

Hide errors: In this overview too you can hide (solve) individual errors and re-show them. The operation is the same as in the “Errors” tab of the client detail view (see Hiding and Re-showing Errors).

Retrieve all logs: Via the Retrieve all button you retrieve fresh error logs from all clients, so the overview reflects the current state across the entire estate.

Charts: Above the table, two charts show the overall picture: Error Trend (30 days) shows the error progression over the last 30 days, By Level the distribution of errors by severity.

Details: Clicking an error row opens the same error detail view as in the “Errors” tab of the client detail view (see “Errors” Tab). The full details are loaded only when opened.

Note: For performance reasons the overview shows at most the 5,000 newest errors. When this limit is reached, a corresponding note appears above the table. Click Refresh to reload the list.

AI Error Diagnosis

The AI Error Diagnosis lets an AI service analyse a captured error and explain to you, in understandable terms, what went wrong and how you can fix it. The function is optional and switched off by default. It only becomes active when you store your own API key from an AI provider (OpenAI or Anthropic) — the use of the AI service is billed directly via your account with the respective provider.

As long as no key is stored, everything at the dashboard stays as usual: no additional buttons and no diagnosis displays appear. PostRequest remains dependency-free even with this function — no additional software is required.

Privacy note: For a diagnosis, the data of the relevant error — the captured error report as well as relevant excerpts of the involved source files — is transmitted to the AI provider you chose and processed there. Only enable the function if this transmission is permissible for your projects. Sensitive information is redacted automatically before processing, as everywhere in PostRequest (see Data Redaction).

Enabling Diagnosis

You enable the function in the Settings area, in the AI Assistant card. The API key you store there powers all AI features of the dashboard: the Explain and Clarify chats as well as the error diagnosis described here.

1. Choose your AI provider and paste your API key (from OpenAI or Anthropic) into the field provided.
2. Click Save. Once the key is stored, the function becomes active throughout the dashboard.

Safe handling of the key: Your API key is stored encrypted and, for security reasons, is never shown in full again. After saving, you only see a masked form (e.g. ••••WXYZ), by which you can recognise the stored key without revealing it.

• Replace the key: Simply paste a new key and save again.
• Remove the key: Via the button to delete the key you disable the function completely again.

Selecting the AI Model

After storing a key, you choose the AI models to be used. The AI Assistant card is organised in two parts: at the top — directly below the API key — you select the Chat model, the default model for the Explain and Clarify chats (changing the model within a conversation updates this setting too). Below that, under the Diagnosis subheading, all settings specific to error diagnosis are grouped together; there you choose the Model used for the diagnoses. The list of available models is fetched live from the provider as soon as a key is set — so you always see the models actually usable for your account. Via the refresh function you can reload the list when needed.

Note on the cost per model: For common models, PostRequest calculates the resulting costs automatically. For a model whose price is not known, the cost is shown as n/a — the diagnosis works regardless.

Automatic Diagnosis (Auto-Diagnosis)

By default you start each diagnosis yourself (see Starting a Diagnosis). Alternatively, in the Diagnosis section of the AI Assistant card you can switch on automatic diagnosis. When it is active, PostRequest diagnoses new, matching errors on its own in the background as soon as they are detected — you then find the finished result directly at the error.

So that the costs stay manageable, you set the scope of the automatic diagnosis:

The diagnosis started manually via the wand button is not affected by these limits — you can trigger a diagnosis yourself at any time.

Usage and Costs

In the Diagnosis section of the AI Assistant card you also see an overview of usage so far: the number of diagnoses performed and the costs incurred for them — each for the last 30 days as well as in total (since the beginning). This way you keep track of how often the function is used and what costs arise.

Starting a Diagnosis (Wand Button)

When the function is active, both error lists — the Error Overview (All Clients) and the “Errors” Tab in the client detail view — get an additional wand button between the “Message” and “#” columns. (If the function is not active, this button does not appear.)

The colour of the wand shows the diagnosis state of the respective error at a glance:

Clicking the wand opens the error detail view directly in the Diagnosis tab (see the next section).

“Diagnosis” Tab in the Error Detail View

When the function is active, the error detail view contains an additional Diagnosis tab — directly after the “Overview” tab. It shows one of several states depending on progress:

• No diagnosis yet: A short introduction and the Start button with which you trigger the diagnosis for this error.
• Diagnosis running: A progress display. The result appears automatically once it is ready.
• Failed: A note along with a button to try again.
• Diagnosis finished: The full report, divided into four sub-tabs (see below), as well as an information line with the model used, a reliability indication (confidence), the costs and the scope of processing. Via the re-run button (Re-run) you can have the diagnosis recreated when needed.

The finished report is divided into four sub-tabs, so you can choose the view that fits your prior knowledge:

Related errors: If PostRequest detects that several different errors belong to the same request (for instance because they occurred for the same visitor, on the same page and almost simultaneously), they are diagnosed together. The diagnosis then takes the whole context into account instead of considering each error in isolation. The information line indicates when related errors were included.

Further buttons in the header of the error detail: With Solved you mark the error as solved (it is hidden — as in the list), with Unsolved you undo this. Full copy copies the raw error report together with the full technical report and the fix instructions to the clipboard.

Follow-up Questions to the AI in Chat (“Clarify”)

For a finished diagnosis, you can open a chat via the Clarify button and ask follow-up questions. The currently displayed sub-tab serves as the starting point of the conversation; the AI additionally knows the other areas and the original error report and can, when needed, read further source files or search for them in the project.

• Asking questions: Type your question into the input field and send it (Enter; Shift+Enter for a new line). The answer appears progressively, word by word. You can keep writing immediately and add further questions.
• Saved history: Your conversation history is stored per user. If you open “Clarify” again later, you continue the conversation where you left off.
• Update the diagnosis: If an answer implies that something should change in the diagnosis, the chat offers buttons to recreate only the current sub-tab or the whole diagnosis — each taking your follow-up questions into account.
• Back: Via Back to report you return to the diagnosis without changing anything.

The costs for follow-up questions are recorded separately from the diagnosis costs.

Excluding Individual Clients from Automatic Diagnosis

When automatic diagnosis is switched on globally, you can exclude individual clients from it — for example projects for which you don't want automatic diagnoses (and thus no costs). By default, every client is included.

There are two ways to do this:

• In the client overview: As long as automatic diagnosis is active globally, an additional Diagnosis column with a wand icon per client appears in the client table. A click toggles the client between included (highlighted) and excluded (dimmed). If global automatic diagnosis is switched off, this column is not shown at all.
• In the client detail view: In the “Actions” Tab — likewise only when automatic diagnosis is active globally — an Auto-Diagnosis section appears with a checkbox with which you can include or exclude the client.

An excluded client is skipped by automatic diagnosis. You can still start a manual diagnosis for its errors at any time via the wand button.

Risk

The Risk area highlights problems before they turn into errors: software that has reached its end-of-life, database changes that could break your app, and TLS certificates that are about to expire. It is an optional, licensed feature; if it is not part of your license, the Risk menu item, the per-client Risk tab and the counters do not appear.

What is checked

• End-of-life (EOL): whether the PHP version (and detected frameworks) your app runs on is still supported. An unsupported version no longer receives security updates and is therefore always a real risk.
• Schema drift: columns or tables that were removed or changed and could break your application.
• Certificate expiry: how long the website's TLS certificate is still valid.

Where to find it

• A Risk entry in the left navigation opens the fleet-wide list across all your clients. The menu item shows a small bubble with the number of open findings (not yet acknowledged or snoozed).
• Every client's detail view has its own Risk tab with the same list scoped to that client, and a count badge on the tab.

The list

Each finding shows its severity, when it was seen, the category, and a Diagnose column:

• Done (with a confidence percentage) — the AI checked the finding against your actual source code.
• Pending — the finding still needs the background analysis (only shown when an AI provider is configured).
• n/a — no AI provider is configured, so no code analysis runs. The finding itself is still valid.
• — — no analysis needed (e.g. a certificate expiry).

Click a finding to expand its details: a highlighted diagnosis header, an Affected files table (file · the affected functions · the number of affected lines) — clicking a file opens the source preview with every affected line highlighted — and a Suggested fix.

Acting on a finding

• Ack acknowledges and dismisses a finding. Snooze hides it for a number of weeks (you are asked how many). Both grey the row out in place, just like a solved error; it disappears into the hidden list on the next refresh. Use Show snoozed to bring hidden findings back, and Reopen to make one active again.
• Rescan now re-runs the full analysis for a client. This happens in the background: you see a "running" note while it works and the list updates automatically when it finishes.

Client Comparison

In the “Compare” area you can compare two clients side by side. This is useful for spotting differences in configuration or system state between two projects — e.g. between a production and a test environment.

1. In the “Client A” dropdown, choose the first client.
2. In the “Client B” dropdown, choose the second client.
3. Click Compare.

The results are shown in a comparison table:

At the top of the results you see the total number of matching and differing properties.

User Management

In the “Users” area you manage the user accounts that have access to the dashboard.

Overview: The table shows all users with the following information:

Invite a new user:

New users are invited by email and set their password themselves — you don't assign a password for them.

1. Click Add User.
2. Enter the email address of the new user.
3. Click Send Invite.

The account is created without a password, and an email with the “Set your password” link is sent to the given address. Until the user has followed this link and set a password, they cannot sign in; in the table their status appears as Pending setup. The invitation link is valid for 7 days.

Resend the invitation or reset link: In each user's row you'll find the action Resend invite (for users with status “Pending setup”) or Send reset (for users who already have a password). Through it you resend the corresponding link.

User Settings

To open a user's settings, click Settings in the user's row. A window opens with several sections:

Change email address (Account):

In the Account section you can adjust the account's email address in the Email field. Since the verification codes of two-factor sign-in are sent to this address, you correct a wrongly stored address here. How the process works depends on whether you change your own address or that of another user.

Change your own address (with a verification code):

So that no one can silently swap the address of your account, a change to your own email address only takes effect after entering a verification code. The code is sent to the new address — this ensures that you actually have access to the specified inbox.

1. Enter the desired new address in the Email field.
2. Click Save. A 6-digit verification code is sent to the new address, and the window switches to the Verify New Email step. There, the target address to which the code was sent is shown.
3. Open the inbox of the new address, find the message with the code and enter it in the Verification Code field.
4. Click Confirm to apply the change. Your current session is preserved — you don't have to sign in again.

If the code does not arrive, click Resend code to request a new one (check your spam folder too if necessary). With Cancel you abort the change; your previous address then remains unchanged.

Change the address of another user:

If, as an administrator, you change the address of another user, the change is applied directly and without a verification code.

1. Enter the desired address in the Email field.
2. Click Save to save the change.

An address that is already used by another user is rejected in both cases.

Change password (your own account only):

You can change your own password here — but only your own. The Change Password section is shown only when you open your own settings; when you view another user's settings it is hidden, and any attempt to set someone else's password is rejected.

1. Enter the new password (at least 8 characters) in the New Password field.
2. Repeat it in the Confirm New Password field.
3. Click Save to apply the change.

If a colleague has forgotten their password, do not try to set a new one for them. Instead, use Send reset in their row (or have them use the Forgot your password? link on the sign-in page); they then choose a new password themselves via the reset link.

Two-Factor Authentication:

The settings window has a Two-Factor Authentication section showing how the account currently receives its login code, with buttons to change it. What you can do depends on whose settings you have open:

• Your own account: If login codes are sent by email, a Set up authenticator app button lets you switch to an app (see Using an Authenticator App). If an app is already active, a Deactivate authenticator button returns the account to email codes.
• Another user's account: You cannot set up an app for someone else — only that person can. You can, however, Deactivate authenticator for them. This is the recovery path when a colleague has lost the phone that held their authenticator app; afterwards that account receives its login codes by email again.

Delete user:

1. Click the delete action in the user's row.
2. A confirmation dialog appears with the note that this action cannot be undone.
3. Click Delete to remove the user permanently, or Cancel to abort.

Send Manual Digest

Via the Digests column in user management, you can send a user a Health Digest manually:

1. Click the number in the Digests column in the row of the desired user.
2. The Send Manual Digest dialog opens.
3. Choose which clients the digest should cover:
   • Subscribed clients — Only the clients the user has subscribed to.
   • All clients — All available clients, regardless of subscription.
4. Click Send to send the digest immediately.

Server Settings

In the “Settings” area you'll find the configuration of the monitoring server. All settings are organised into clear cards.

Server Info:

Here you see the unique server identifier (Server ID) and the current secret. For security reasons the secret is hidden at first — click Show to display it.

Server Version:

The “Server Info” area additionally shows when the server was last updated. The time is shown in the server's local time (with timezone):

• Last updated: <date/time> — when the software has already been updated via the dashboard, this line shows the time of the last successful update.
• Installed: <date/time> (not yet updated) — when no update has yet been performed via the dashboard, this line shows the installation time instead.
• Build <hash> — a short, read-only identifier of the exact program build you are running (it matches the name of the release package it came from). This line appears only for a packaged build; when the dashboard runs directly from the source code, there is no build identifier and the line is omitted.

Next to the display you'll find the Software Update button, with which you go directly to the Software Update page.

Regenerate the secret:

1. Click Regenerate.
2. A warning appears: if you renew the secret, all connected clients must be configured with the new secret. Existing connections will no longer work until the clients are updated.
3. Click Regenerate in the dialog to proceed, or Cancel to abort.

Framework Detection Rules:

Here you can adjust the rules by which PostRequest detects systems and frameworks on the monitored projects. Each rule is shown as its own card that you can expand and collapse.

Detection runs on the server, based on each client's file list, so it is files-based only. Whether a framework is present is decided solely by the “Files to detect” field: all listed entries must be present. An entry ending in / (e.g. typo3/) matches a directory. (The earlier “Constants” and “Globals” fields have been removed, because the server cannot see the running state of the monitored application.)

Reading a version is optional and is configured as a list of version sources. Each source consists of a file the server fetches plus an optional regular expression whose first capture group is the version (leave the pattern empty to use the whole file when it already contains only the version). You can add several sources; they are tried in order until one matches. This is useful when a framework's version file moved across releases — you simply list every possible location. Defaults ship for WordPress, Laravel, Symfony and Drupal; TYPO3 comes with two version sources (a current file plus a legacy fallback), and Craft ships with none. If no version source is configured, no version is read.

The version is read only when the file list (sitemap) is refreshed, not on every heartbeat.

Each rule card contains the following fields:

Managing rules:

• Add a new rule: Click + Add Rule to add a new, empty rule card.
• Remove a rule: Click the × in the card's header. A rule without a name is treated as a draft and is not saved, so removing an unfinished card never affects your saved set.
• Reorder: Drag a card by the handle icon (☰) on the left of the header to the desired position.
• Expand/collapse a card: Click a card's header to show or hide its fields.

Automatic saving: There is no Save button. Every change is saved on its own — text edits are saved shortly after you stop typing, while adding, removing and reordering rules are saved immediately. A small status next to the “+ Add Rule” button shows the progress (“Saving…” / “All changes saved”).

Deletable defaults: The built-in default rules can be deleted completely. An intentionally emptied rule set is honoured — the defaults are not restored on their own. When you have deleted every rule, an Add default rules button appears, with which you can restore the built-in set at any time.

Data redaction (configured on the client):

Redaction of sensitive fields is owned by each monitored client and configured there, not in the dashboard. In the client's init() configuration you can list additional field labels to always redact (redaction_blacklist) or to exempt from redaction (redaction_whitelist). Because the lists live on the client, a server can never add to or relax a client's redaction — it cannot widen what a client discloses. See Data Redaction for how redaction works.

Error Period:

Here you set over how many days errors are counted for warnings. This setting affects the “Errors” column in the client overview, the status displays (health dots), the Errors badge in the detail view and the Health Digest.

The setting is saved automatically as soon as you change the value.

Note: The “Errors” tab in the client detail view shows all captured errors regardless of this setting.

Health Digest:

Here you set the default frequency for Health Digest notifications. This setting serves as the default value for all new users.

The setting is applied immediately when you choose an option.

Note: This setting acts as a default for new users. Existing users can change their personal digest frequency on the “Users” page (see User Management). The frequency can additionally be adjusted individually per client (see Health Digest).

API Access (MCP):

This card lets you expose the dashboard's read-only fleet tools (client list, heartbeats, errors, diagnoses, DNS, sitemap, code search and more) to any MCP client — such as Claude Desktop or Claude Code — so you can query your fleet from an AI assistant. Access is authenticated with a personal API token that acts as your account, so treat a token like a password. The tools are read-only: an MCP client can look at your data, but cannot change any settings or trigger any actions.

MCP endpoint:

The MCP endpoint (Streamable HTTP) field shows the URL you point your MCP client at. Use Copy to copy it. There are two ways to authenticate:

• API token — paste a token you create below into your MCP client.
• OAuth — clients that support OAuth (e.g. Claude's custom connectors) can just point at the endpoint URL; they register automatically and send you here to sign in and authorize, with no token to paste. OAuth grants the same read-only access and issues a token that then appears in the list below, revocable at any time.

Creating a token:

1. Enter a name so you can recognise it later (e.g. “Claude Desktop”).
2. Choose a lifetime: expires in 90 days, 30 days, 1 year, or never.
3. Click Create token.
4. The new token is shown once — copy it immediately, because it will not be shown again. Store it like a password.

Requests are rate-limited per token.

Your tokens are listed in a table:

Recent activity:

Below the token list, the Recent activity table is an audit log of the most recent tool calls made with your tokens, so you can see how your API access is being used:

The list is paginated at 10 entries per page — use Prev / Next to page through it (the pager appears only when there are more than 10 entries). Refresh reloads the log and returns to the first page.

Background Refresh

In the “Background Refresh” section you can set up automatic background refresh. When this function is enabled, the server retrieves error logs and heartbeat data from all connected clients on its own at regular intervals — without you having to trigger each client individually in the dashboard.

Settings:

How to set up background refresh:

1. Enable the Enabled checkbox.
2. Set the desired interval in the Refresh Interval (hours) field — e.g. 24 for once a day. The settings are saved automatically.
3. Set up the cron dispatcher: You'll find the command to enter in the Cron Jobs card directly below this card — a single line is enough to enable all background tasks. Contact your server administrator for the exact setup.

Security: The refresh command can be executed only via the command line. A call through the browser is blocked automatically.

Note: Setting up the cron dispatcher on the server is done by your server administrator. The exact procedure depends on your operating system and hosting provider.

Last refresh per client:

Below the settings you see the “Last Refresh per Client” table. This shows, for each connected client, the time of the last background refresh — the most recently refreshed clients first:

The list is paginated at 10 entries per page — use Prev / Next to page through it (the pager appears only when there are more than 10 entries). If no background refresh has been performed yet, the note “No background refresh runs recorded yet.” appears.

Cron Jobs

Below “Background Refresh” you'll find the Cron Jobs card. Instead of four separate crontab entries, you add only a single line to your server's system crontab — the cron dispatcher. It runs every minute and automatically triggers the individual jobs (Health Digest daily/weekly, background refresh, cleanup of orphaned download files) at their configured times.

The card is in two parts:

• At the top you see the line for the dispatcher with a Copy button. This one line is enough to set up all jobs.* * * * * php /path/to/your/project/cron/dispatch.php
• Below it the four jobs are listed individually — each with a status dot and last run time, but without a Copy button (they are triggered by the dispatcher and don't need to be installed separately).

For each entry you see:

• A coloured status dot — green: running as scheduled; yellow: last run failed; red: never run or overdue.
• The time of the last run (relative, with an absolute timestamp on hover).
• For a failed run, additionally the error message.

You need to enter the single dispatcher line on the server once, in the system crontab (crontab -e) or in your host's task scheduling tool — the dashboard does not install it automatically. The individual scripts (cron/digest.php, cron/refresh.php, cron/sweep_orphan_downloads.php) remain usable for manual single runs.

Note: If the dispatcher's status line turns red or shows “Overdue”, the central cron dispatcher itself is not running — in that case all the other jobs below it are not executed either.

Software Update

In the “Software Update” area you can update the PostRequest software to a new version directly through the dashboard — without SSH access, without Git and without manually uploading individual files. You only upload a ZIP archive of the new version; the dashboard checks it, automatically creates a backup of the existing installation and then applies the full new version. Newly added program components are taken over too — even entire new folders that were not yet contained in the previous version.

This page is available to administrators only. It is the convenient alternative to a manual update (see also When the In-App Update Is Unavailable) and is only usable when the server may overwrite the program files itself.

How to reach the page: The Software Update page is no longer reachable via its own entry in the sidebar. Instead, open it via the server settings: Settings area → Server Info card → Software Update button (see Server Settings).

Important: Your stored data is never affected. The data directory (where clients, users, settings and captured errors are kept) is changed neither during an update nor when rolling back. Only the program files are updated.

Ready to use immediately after the update: After an update applied via the dashboard, the dashboard can be used directly without further steps — all pages open normally and are shown correctly with their familiar appearance, just as with a fresh installation. Earlier versions could lead to an error page or an incompletely rendered page after an update; that is no longer the case.

Checking Requirements (“Current state”)

At the top of the page you see the current state in the Current state card:

• In-app updater — A badge shows whether an update through the dashboard is possible: Available or Unavailable.
• Installed version — The currently installed version, if it can be determined.
• Below it follows a checklist with the most important requirements (e.g. whether the necessary archive support is available, whether the program directory is writable, whether a location for backups exists and whether there is enough free disk space). Each item has a badge; when there are problems, an explanatory hint with a suggested solution appears.

If an item with the note “Action needed” appears here, you should fix it first and then reload the page.

Applying an Update

1. Download the desired version as a ZIP file from the project's official GitHub page. Both variants work: the source code's “Download ZIP” button as well as a published release archive. It doesn't matter whether the archive contains an enclosing folder — it is detected and skipped automatically.
2. In the dashboard, open the “Software Update” page via Settings → Server Info card → Software Update.
3. In the Upload an update card, use the “Update archive (.zip)” file field to select the downloaded ZIP file. Note the displayed maximum file size (default 64 MiB).
4. Click “Validate & apply update”. A safety prompt appears in which you must confirm applying the update.

The dashboard then checks the archive, ensures that it is actually a valid PostRequest version, creates a full backup of the current installation and then applies the new version.

After a successful update you see the message “Update applied successfully” as well as:

• Backup created — the identifier of the created backup (for a later rollback).
• Replaced and Created — which program components were replaced or newly created.
• A note to check the dashboard afterwards: to be safe, open further pages (e.g. “Clients” or “Settings”) in a new tab. Should something be wrong, you can restore the previous version via the backups below.

Cleaning up outdated files: When applying, program files that belonged to an earlier PostRequest version but are no longer contained in the new version are removed automatically. This way no outdated file is left behind. These removed files are included in the backup and can therefore be restored during a rollback. Files and folders you created yourself and that were never part of a PostRequest version remain untouched.

Automatic safeguard: If an error occurs while applying, the previous version is automatically restored from the backup created beforehand. In this case, a corresponding note appears instead of the success message. Should the automatic restore exceptionally not complete, you can roll back the previous version manually via the backups below.

Backups and Rolling Back

In the Version history card you see the full version history of your installation. The table lists all retained versions as well as the currently running version — the newest is at the top. This way you have every state you can return to, together with the currently active version, at a glance. Before each update a backup is created automatically; the last three are retained.

The table shows, for each version:

• Date — Date and time when the respective state was created (below it, if applicable, the technical identifier). For the running version, the note “Currently running” additionally appears here; if no time is known for it, a dash (—) appears instead of the date.
• Size — the size of the respective state.
• Performed by — who created the state. For an update applied via the dashboard, the email address of the administrator who performed it appears here. If the state does not come from a dashboard update, an explanatory indication appears instead (see Type).
• Type — the kind of entry:
  • Initial version — the original state at the initial installation (no user recorded).
  • Manual update — a state changed outside the dashboard (e.g. by directly replacing files on the server).
  • Update — an update applied regularly via the dashboard.
  • Restore point — a safety copy created automatically before a rollback (see below).

This way you can always trace when an update took place, how large the respective state is and who applied it.

The active version: Exactly one row is marked with the “● Active” label and highlighted — that is the version currently running. This label stands where the “Roll back” button appears for the other rows; it is designed as a label and is not clickable. The active version has no “Roll back” button, because you cannot roll back to the state already running. If the running version corresponds to an already retained state (e.g. after you rolled back), exactly that existing row is marked as active — no duplicate row is created.

As long as no update has been applied yet, there are no retained backups; in that case the note “No restore points yet” appears. A backup is created automatically with the first update applied via the dashboard.

To return to an earlier version:

1. Find the desired version in the table by date and description.
2. Click “Roll back” in the corresponding row.
3. Confirm the safety prompt. The current program files are then reset to the state of the chosen version — including the files that had been removed during the update. Those are thus restored.

After completion the message “Rollback complete” appears. The rollback fully restores the previous state: both the program files replaced during the update and those removed at the time. Here too: the data directory remains unchanged — only the program files are rolled back.

Forward again possible: Before a rollback is carried out, the dashboard first automatically backs up the current state as an additional safety copy (marked in the table as a Restore point). This way you can, after a rollback, switch forward again at any time to the previously active version — a rollback is thus never a one-way street. This safety copy is, however, only created when the current state is not already contained in another backup — so no duplicate entries arise for one and the same version. If you roll back several times in a row, such a copy is likewise not created again at every step.

When the In-App Update Is Unavailable

If the server cannot overwrite the program files itself (missing write permissions of the web server in the program directory), an update through the dashboard is not possible. In this case the Current state card shows the Unavailable badge, and instead of the upload card the “In-app updates are unavailable” section appears with concrete suggested solutions.

You can then still update the software in the traditional way: replace the program files directly on the server (e.g. via Git or file transfer) and leave the data directory unchanged in its place. In this case too, your stored data is preserved.

Health Digest

The Health Digest is a regular email summary of the state of your monitored clients. The email shows at a glance which clients are reachable and which are not — so you keep an overview even without signing in to the dashboard.

Set the default frequency:

You set the default frequency for new users on the “Settings” page (see Server Settings). Existing users can adjust their personal digest frequency individually on the “Users” page.

The user setting acts as a default for all clients. Individual clients can be configured to deviate from it (see below).

Adjust the digest per client:

There are two ways to change the digest frequency for individual clients:

• In the client overview: Click the bell icon (🔔) in the respective row. The icon advances to the next state on each click: None → Daily → Weekly → None. Changes are saved immediately. Further information can be found under Digest Notifications.
• In the client detail view: Open the “Actions” tab and scroll to the Notification Recipients section. There you see all users with their current frequency and can change it directly.

Sender address:

The digest emails are sent from the noreply@ address of your dashboard domain (e.g. noreply@my-server.com). No additional configuration is required — the address is determined automatically from your dashboard's domain.

Content of the digest email:

The email contains an overview of all clients for which the digest is active:

• A summary of how many clients are reachable and how many are not.
• If unreachable clients exist, they are highlighted separately.
• A table of all subscribed clients, sorted alphabetically by display name, with the following columns:

Manually triggered digests (see Send Manual Digest) are marked as “Manual” in the email.

Direct links in the email: The digest email contains clickable links that take you directly to the matching place in the dashboard:

• Each client name is a link that opens the associated client detail view.
• Each listed reappeared error links directly to the error list of the relevant client (“Errors” tab).

Note on status: The state of each client is re-checked immediately before the digest is sent. The digest therefore reflects the actual state at the time of sending. For the daily digest, all clients are updated beforehand, so that reappeared errors too are reliably detected on the basis of fresh data.

Notification for reappeared errors:

When a hidden (solved) error recurs (see Hiding and Re-showing Errors), the user who had hidden the error is notified by email about the recurrence. This notification is delivered via the daily Health Digest.

• You receive exactly one notification per recurrence — multiple hints about the same event are combined and not sent twice.
• The notification is sent even if you have not set up a digest subscription for the relevant client (or in general). For this notification, the affected clients are included in the email regardless of your subscriptions.

Managing Subscriptions via the Email Link

Every digest email contains a personalised link for managing your own subscriptions. Via this link you reach a management page where you can adjust your digest settings directly — without signing in to the dashboard.

The management page shows all clients for which you received notifications at the time the email was sent. For each client you choose the desired frequency from a dropdown:

Changes are applied immediately when you choose an option. The link is permanently valid — you can access it again at any time to adjust your settings. The link always leads to the right place, regardless of whether your dashboard is run directly under the main address, under /dashboard/ or in a subfolder (see Deploying the Dashboard).

Note: Via this link, only the clients that were included in the respective email can be managed. New clients cannot be added. Other dashboard settings are not accessible via this link.

Available Functions

Initialization

PostRequestClient::init([...]);

Starts monitoring with the given configuration. Can be called multiple times within a single page visit — error capture is activated only on the first call; on further calls only the server list is updated.

Restoring a Server Connection

PostRequestClient::retryServer('https://monitor.example.com');

If the handshake with a server has failed, you can use this function to trigger another connection attempt. Existing keys and logs are preserved.

Optionally you can pass a retry-protection token to prevent duplicate calls within 10 minutes:

PostRequestClient::retryServer('https://monitor.example.com', 'my-token-123');

Resetting a Server

PostRequestClient::resetServer('https://monitor.example.com');

Fully resets all data for a specific server: keys, logs, cache. On the next start, a completely new handshake is performed.

Caution: Error logs for this server that have not yet been retrieved are lost in the process. If you merely want to retry a failed handshake, use retryServer() instead.

Complete Restart

PostRequestClient::resetAll();

Deletes all stored data: all server connections, keys, logs and caches. On the next start, PostRequest begins completely from scratch.

Both reset functions likewise support an optional retry-protection token:

PostRequestClient::resetAll('my-token-456');

Status and Diagnostics

Multi-Server Operation

PostRequest supports connecting to multiple monitoring servers at the same time. This is particularly useful when different teams monitor the same project (e.g. the development team and the hosting provider).

PostRequestClient::init([
    'servers' => [
        [
            'endpoint' => 'https://monitor-team-a.example.com',
            'secret'   => 'secret-team-a'
        ],
        [
            'endpoint' => 'https://monitor-team-b.example.com',
            'secret'   => 'secret-team-b'
        ]
    ]
]);

Important properties of multi-server operation:

• Each server works completely isolated, with its own keys, logs and caches.
• When server A retrieves the error logs, the copies for server B remain untouched.
• Each server has its own secret — one server cannot access another's data.
• You can reset individual server connections specifically, without affecting the others.

CLI Mode

PostRequest automatically detects whether it is running on the command line (e.g. in cron jobs or maintenance scripts). In CLI mode:

• Error capture remains fully active.
• Web-specific functions (such as the request ring buffer and the routing for server requests) are disabled automatically.
• No additional configuration is required.

// Works identically in web and CLI:
require_once 'PostRequestClient.php';
PostRequestClient::init([
    'servers' => [['endpoint' => 'https://monitor.example.com', 'secret' => '...']]
]);

// Your script continues to run normally — errors are captured.

Security

Encryption

PostRequest uses a multi-stage encryption process:

1. Key exchange: During the handshake, client and server exchange keys. Each server receives its own key pair — full isolation.
2. Data encryption: All stored error logs are encrypted with a daily key. This key is in turn secured with the server key — only the associated server can decrypt the data.
3. Transmission encryption: All responses to the server (heartbeat, file lists, file transfers) are encrypted.
4. No plain-text data on disk: Neither error logs nor cached files or redaction indexes are stored unencrypted.

Data Redaction

Sensitive data is detected automatically and redacted before it is stored or transmitted:

• Passwords, credentials, security keys — detected in over 40 European languages (German, English, French, Spanish, Italian, Russian, Polish, Turkish and many more)
• Patterns in values — cloud credentials, payment information, certificates, connection strings and embedded passwords in error messages
• Configuration files — during file transfer, sensitive values in environment files, configuration files and other formats are redacted

Redaction replaces only the values, not the key labels. This preserves the context for error analysis while the actual secrets are protected.

Each redaction receives a unique identifier, so the server can trace the assignment when needed.

Safety list: Certain especially sensitive field labels can never be exempted from redaction. Redaction is owned by the client itself — a compromised or misconfigured server can never release sensitive data a client would otherwise protect.

Client-configured lists: Redaction is configured on the client, in its init() configuration — not in the dashboard. You can force additional field labels to always be redacted (redaction_blacklist) — for project-specific confidential fields PostRequest would not recognise on its own — and exempt specific labels from redaction (redaction_whitelist). If a label appears in both lists it is redacted (the blacklist takes precedence), and the safety list above can never be exempted.

HTTPS Requirement

PostRequest refuses the handshake with servers that do not use an encrypted connection (HTTPS). This prevents keys and data from being intercepted during transmission.

If you deploy the monitoring server via Option 2 (see Deploying the Dashboard), all requests over an unencrypted connection (HTTP) are automatically redirected to HTTPS. You don't need to configure anything extra for this — the protection is active by default on the Apache web server.

Access Protection for Stored Data

PostRequest stores all data in a directory with a random, unguessable name.

• On Apache: An access rule is created automatically that blocks direct access through the browser.
• On Nginx: The random directory name provides a basic protection. For optimal security you should explicitly block access to the log directory in your Nginx configuration. Ask your server administrator for the exact configuration.

If you use the entire project directory as the web root (see Deploying the Dashboard), on Apache web servers all files and directories outside the dashboard are automatically protected from browser access. This protection is multi-layered: in addition to the central access rule in the main directory, each subdirectory (source code, tests, documentation, data) has its own independent access rule. Even if a single protection layer were to fail, the files remain protected by the other layers. Internal project files such as source code, documentation and configuration files are thus not reachable over the internet.

Storage location of the dashboard data: All data stored by the dashboard — user accounts, sessions and access logs — is placed by default outside the area reachable through the browser. This means that these data are not accessible over the internet even if the web server were misconfigured. This storage location is set up automatically and requires no manual configuration.

Licensing

PostRequest is proprietary, licensed (not sold) software. The monitoring client keeps collecting data on your applications at all times, but the dashboard requires a valid license key to open. See the LICENSE file for the license terms; current editions, features and pricing are published at postrequest.com.

Activating your license

1. You receive a license file (license.key) from PostRequest.
2. Open the dashboard. Until a valid key is installed you are taken to a license page instead of the normal dashboard.
3. Upload the license.key file on that page. The dashboard unlocks immediately.

You can review the installed license at any time under Settings → Licensing, which shows who the license is issued to, its edition, expiry, and the days remaining.

What a license controls

A license can carry any of the following limits, all enforced by the dashboard:

• Edition — a named tier (for example standard or pro).
• Features — individual capabilities may be included or withheld: File preview & download, API access (MCP), AI Diagnosis, AI Explain, and DNS. When a feature is not licensed, its dashboard menus, settings and actions are hidden and the corresponding server-side operations are refused. A license that lists no features grants them all.
• Client limit — the maximum number of monitored clients shown. Data from every client keeps being collected; if the limit is exceeded, only the longest-registered clients are shown, and the list tells you how many are hidden and links to the licensing page.
• Domain binding — a license may be restricted to one or more host names. An empty domain list means the license is valid on any host.
• Validity period — the license has an expiry date. An expired license sends the dashboard back to the license page; your monitored applications keep reporting in the meantime, so no data is lost. Upload a renewed key to restore access.

Expiry and renewal

Before a license lapses, request a renewed license.key from PostRequest and upload it the same way you activated the first one — there is nothing else to reinstall. Reassigning or renaming a license does not require re-issuing it.

Tamper protection

Distributed builds ship with a signed integrity manifest. If the licensing or enforcement files are modified, the dashboard refuses to run and reports that the application files no longer match their signed release. Restore the original files from your PostRequest package to continue.

Build and Distribution

The Client File

PostRequest ships the monitoring client as a single file, PostRequestClient.php. This is a hardened, obfuscated build: it behaves exactly like the readable source code, but is compacted and protected for use on production servers. You integrate this one file into your project exactly as shown in the Quick Start — there are no separate variants to choose between and no build step for you to run.

Getting the Client File

You obtain PostRequestClient.php in one of two ways:

• From your PostRequest package — the file is included in the delivered package, ready to integrate.
• From the dashboard — when you add a client, the add-client overlay lets you copy the ready-to-use setup snippet or download PostRequestClient.php directly (see Adding a Client).

In either case the file is complete and self-contained. You include it as shown in the Quick Start:

require_once __DIR__ . '/PostRequestClient.php';

To update the dashboard software itself to a newer version, use the Software Update page instead — no manual file building is involved.

Troubleshooting

Handshake Failed

Symptom: PostRequest captures errors, but the monitoring server does not show the client as connected.

Possible causes and solutions:

• Server unreachable: Check that the server URL is correct and the server is online.
• Wrong secret: Compare the secret in your configuration with the value provided by the server administrator.
• No HTTPS connection: PostRequest requires an encrypted connection. Make sure the URL begins with https://.
• Firewall blocks outgoing connections: Your web server must be allowed to establish outgoing connections to the monitoring server.
• Timeout: The handshake has a time limit of 10 seconds. On a slow connection this can be exceeded.
• A path appended to the server address: The address must be the plain dashboard address (e.g. https://monitor.example.com), without an appended path. An address ending in /handshake — as described in older versions of this guide — leads nowhere on the server (it answers with "Forbidden" or "Not found", depending on the installation) and the connection fails.
• Wrong parameter name: The server entry must use endpoint (not url). An entry with a different key name is silently ignored, so no connection attempt is made at all.

Solution: Use retryServer() to retry the handshake:

PostRequestClient::retryServer('https://monitor.example.com');

No Error Logs Present

Symptom: The monitoring server shows no errors, although you know that some occur.

Possible causes and solutions:

• PostRequest not initialized: Make sure init() is actually called. Check with PostRequestClient::isInitialized().
• Integration too late: Include PostRequest as early as possible, ideally first in your application.
• No write permissions: The web server needs write access in the directory of the PostRequest file. Check the log path with PostRequestClient::getLogDir().
• Handshake not yet completed: Without a successful handshake, no logs can be transferred to the server. The errors are nevertheless stored locally.
• Memory limit reached: With very little available memory, PostRequest switches to a minimal mode with reduced information.

Encryption Unavailable

Symptom: PostRequest reports that encryption is unavailable, or the handshake fails.

Solution: The OpenSSL extension must be enabled on your server. Contact your hosting provider if it is not available. Without OpenSSL, PostRequest cannot establish encrypted communication and cannot perform monitoring.

Storage Space Issues

Symptom: The log files take up too much disk space.

Solution: PostRequest limits the total size of the logs to 50 MB by default. Older entries are deleted automatically (FIFO principle). You can adjust the limit:

PostRequestClient::init([
    'servers' => [...],
    'max_log_size' => 20971520,  // 20 MB
]);

For a complete restart, you can delete all data:

PostRequestClient::resetAll();

Existing Error Handling No Longer Works

Symptom: After including PostRequest, your own error handling behaves differently.

This should generally not happen. PostRequest is designed to insert itself seamlessly into existing error-handling routines without changing their behaviour. If problems nevertheless occur:

• Make sure you are using the current version of PostRequest.
• Check whether another plugin or component overwrites the error handling after PostRequest. PostRequest detects this and re-registers itself automatically.

Cannot Sign In to the Dashboard

Symptom: You cannot sign in to the dashboard, although email address and password are correct.

Possible causes and solutions:

• Account locked: After several failed sign-in attempts, sign-in is temporarily locked. Wait out the displayed lockout time and try again.
• Wrong password: Check upper/lower case and make sure no space was entered accidentally. If you can't remember it, use the Forgot your password? link on the sign-in page to reset it.
• Second factor unavailable: If your account uses an authenticator app but you no longer have the phone, resetting the password alone won't get you in — a reset does not switch off the app. Have a colleague deactivate your authenticator (see Authenticator App Not Working or Phone Lost).
• Initial setup not yet done: If you are opening the dashboard for the very first time, you must first create an administrator account (see Initial Setup).

Background Refresh Not Running

Symptom: You have enabled background refresh, but the “Last Refresh per Client” table shows no updates.

Possible causes and solutions:

• Cron dispatcher not set up: Background refresh requires a cron dispatcher on the server. Enabling it in the dashboard alone is not enough — the command from the Cron Jobs card (under “Settings”) must be set up as a cron job. Contact your server administrator.
• Background refresh disabled: Check under “Settings” → “Background Refresh” whether the “Enabled” checkbox is enabled, and click Save.
• Interval not yet reached: Clients are only updated when the configured interval has elapsed since the last update. With an interval of 24 hours, the next update happens only after 24 hours.

Verification Code Not Arriving

Symptom: After entering the password, a verification code is requested, but the email does not arrive.

If your account uses an authenticator app, no email code is sent — the code comes from the app on your phone. This section applies only to accounts that receive their code by email. For app problems, see Authenticator App Not Working or Phone Lost.

Possible causes and solutions:

• Spam folder: Check your spam or junk folder.
• Delay: Dispatch can take a few minutes. Wait a moment before requesting a new code.
• Request the code again: Click Resend code on the confirmation page to receive a new code.
• Wrong email address: Check that your account's stored address is correct. You can correct it via the user settings in the Email field (see User Settings).
• Emergency access on a new installation: If a code has never arrived on a freshly configured server, you can sign in once without a code via the E-mail not received? button, in order to fix the email problem. This option disappears as soon as email dispatch has demonstrably worked once (see Two-Factor Authentication).
• Email delivery: If the email persistently does not arrive, contact your server administrator to check the server's email configuration.

Authenticator App Not Working or Phone Lost

Symptom: Your account uses an authenticator app, but you can't sign in with the code it shows — or you no longer have the phone.

Possible causes and solutions:

• Code already used: If you see “That code was already used. Wait for your authenticator app to show the next one, then enter it.”, you entered a code that had already been used once. Wait for the app to display the next code and enter that.
• Wrong or out-of-date code: The app changes the code every few seconds. Make sure you enter the code currently shown, in full and without spaces, before it changes.
• Phone clock is off: Authenticator codes depend on the phone's time. If your phone's clock is set manually and drifts, the codes may be rejected. Switch the phone to automatic (network) time and try again.
• Lost or replaced phone: Ask any colleague with dashboard access to open your user settings (Users page → Settings in your row) and click Deactivate authenticator. Your account then falls back to email codes, and you can sign in with an emailed code again. You can set up the app again afterwards on your new phone.
• Forgot your password as well: A password reset does not switch off the authenticator, so if you have lost both your password and the phone, first have a colleague deactivate your authenticator, then use the Forgot your password? link to set a new password and sign in with an email code.

Frequently Asked Questions

Does PostRequest slow down my website? No. The handshake happens only once, at the very first page visit. After that PostRequest works purely passively — it merely stores occurring errors locally. The actual communication is initiated solely by the server.

What happens if the monitoring server is offline? PostRequest works completely independently of the server. Errors continue to be captured locally and stored encrypted. As soon as the server is reachable again, it can retrieve the stored logs.

Can PostRequest crash my application? No. PostRequest is built so that it never produces visible errors itself. All internal operations are safeguarded. In the worst case (e.g. missing write permissions) PostRequest simply captures no errors — your application continues to run undisturbed.

Is my data transmitted securely? Yes. PostRequest enforces HTTPS for all connections and additionally encrypts all data. Even if someone could intercept the transmission, the content would not be readable.

Can I remove PostRequest at any time? Yes. Simply remove the PostRequest file and the associated initialization call from your code. You can also delete the automatically created log directory. PostRequest changes no databases and no other files of your application.

Does PostRequest support multiple monitoring servers? Yes. You can configure any number of servers. Each server works completely isolated — with its own keys and its own log copies. See Multi-Server Operation.

Does PostRequest work in cron jobs too? Yes. PostRequest automatically detects command-line mode and adapts accordingly. Error capture works as usual.

My website is password-protected — do I have to configure the credentials? Yes. For privacy reasons PostRequest collects no credentials on its own. Either set them explicitly via http_auth, or enable the restricted automatic pickup with 'http_auth' => 'auto'. Further information can be found under Password-Protected Websites.

How much disk space does PostRequest need? By default, a maximum of 50 MB for error logs. Older entries are deleted automatically. You can adjust this limit during configuration.

What happens to identical errors that occur repeatedly? PostRequest detects duplicate errors automatically and combines them — even across multiple page visits. Instead of storing the same error hundreds of times, a counter is incremented and the time of the last occurrence is updated. Up to 5 different contexts (e.g. different pages on which the error occurs) are retained to make troubleshooting easier. The monitoring server additionally shows a breakdown by user and environment. The duplicate-detection state is kept for 7 days by default. After that, a previously known error is captured again as a new entry when it recurs. You can adjust this retention period via the dedup_ttl_days setting (see Optional Settings).

Do I have to update the PostRequest file regularly? Updates are done manually. The monitoring server can detect which version you are using and shows you when a newer version is available. There is deliberately no automatic update — this is a security decision.

Can multiple people work in the dashboard at the same time? Yes. In the “Users” area you can create any number of user accounts. Each user signs in with their own email address and their own password.

Why do I have to enter a verification code at every sign-in? Two-factor authentication protects the dashboard from unauthorised access. Even if someone knows your password, they cannot sign in without the second factor — a code sent to your email or generated by your authenticator app. When you enable the “Remember this device for 30 days” option, the repeated sign-in on this device is skipped for 30 days.

Can I use an authenticator app instead of email codes? Yes. Open your own user settings (“Users” page → Settings in your row), and in the Two-Factor Authentication section click Set up authenticator app. Scan the QR code with an app such as Google Authenticator, Authy or 1Password (or type in the shown secret), then enter the code the app displays. From then on your login codes come from the app and no email code is sent — both for the normal sign-in and for the authorisation screen of external applications. Further information can be found under Using an Authenticator App.

I lost the phone with my authenticator app — how do I get back in? Ask any colleague with dashboard access to open your user settings and click Deactivate authenticator. Your account then receives its login codes by email again, so you can sign in with an emailed code. You can set the app up again on your new phone afterwards. (Only the account owner can set up an app, but anyone can deactivate one — precisely so a lost phone doesn't lock you out.)

I forgot my password and also lost my authenticator phone — what now? Resetting your password only proves you own the email address; it does not switch off an active authenticator app. So first have a colleague deactivate your authenticator (see above), then use the Forgot your password? link on the sign-in page to set a new password, and sign in with an emailed code.

What do I do if the verification code does not arrive on a new installation? So that you don't lock yourself out, the confirmation page shows the “E-mail not received?” button as long as a code has never been successfully entered on the server. With it you sign in once without a code, in order to fix the email problem — usually it's because email dispatch is not working or the stored account address is wrong. As soon as a real code has been confirmed for the first time, this button disappears, and a code is required from then on. Further information can be found under Two-Factor Authentication.

What happens if I regenerate the server secret? All connected clients lose the connection to the server until they are configured with the new secret. Use this function only when you deliberately want to renew the secret (e.g. on suspicion of a compromise).

Can I change the environment or project name of a client in the dashboard? Yes. Open the client's detail view and switch to the “Actions” tab. In the “Identity” section you can override environment, project name and tags on the server side. These values take precedence over the settings sent by the client. When you leave a field empty, the value transmitted by the client still applies. In addition, you can set an automatic refresh interval and notification recipients there.

Can I have the data in the dashboard refreshed automatically? Yes. Open the client's detail view, switch to the “Actions” tab and enter an interval under “Auto Refresh (minutes)” (e.g. 30). In the client overview, each client is then updated automatically at its individual interval — recognisable by the loading icon that briefly appears in the respective row. In the detail view, the data of the currently open tab is likewise refreshed at the set interval.

Can I compare two clients directly? Yes. Use the “Compare” area in the sidebar. Choose two clients and click “Compare” to compare their system states side by side. Differences are highlighted.

Can the server retrieve errors and heartbeats automatically without me having to click manually? Yes. Set up background refresh. Go to “Settings”, enable the “Enabled” checkbox in the “Background Refresh” section and set the desired interval. Then your server administrator must set up the cron dispatcher: you'll find the command to enter under “Settings” in the Cron Jobs card. The server then automatically retrieves error logs and heartbeat data from all clients. Further information can be found under Background Refresh.

What is the Health Digest?

The Health Digest is a regular email that summarises the current reachability status of your monitored clients. The default frequency for new users is set on the “Settings” page. Each user can adjust their personal digest frequency on the “Users” page. For individual clients, the frequency can additionally be changed via the bell icon (🔔) in the client overview. Further information can be found under Health Digest.