Limits
This page lists the limits that Guardioz enforces today, and what happens at each one. Messages are written here exactly as they appear. What Guardioz supports is a different question, answered on Requirements.
Install and registration
Section titled “Install and registration”| Limit | Value | What happens at the limit |
|---|---|---|
| PostgreSQL version | 18 | The installer reads the version of each instance it finds, and stops before it changes anything when none of them runs PostgreSQL 18. Guardioz checks again at registration and refuses the server with a message that names the version it found. A refused version does not use up the install command. |
| Servers per organization | 3 on the Free plan, 5 on the Team plan, no limit on the Scale plan | Guardioz refuses a new server at registration, with a message that names the plan, and the refusal does not use up the install command. Running the installer again on a host whose agent configuration for that port still names the same Guardioz address and holds a working key of the server connects to that server and does not count as a new server; without that configuration it registers a new server, which counts. Every registered server keeps being checked, also when the organization has more servers than its plan includes. Deleting a server frees its place at once. The setup page behind + Add server shows how many servers the organization has. See Registration failed because the plan has no place for another server. |
| Install command validity | 60 minutes | Registration fails with Setup token has expired. Generate a new install command in Guardioz and run it again. See Install the agent. |
| PostgreSQL instances per install command | 1 | The installer registers one instance and changes nothing on the others. On a server with more than one PostgreSQL 18 instance it asks for the number of one, or takes the port from GUARDIOZ_PORT. Without a terminal and without GUARDIOZ_PORT it stops before it changes anything. A second registration with the same command fails with Setup token has already been used. See Install on Linux. |
| PostgreSQL instances per server | 1 | A server that runs more than one PostgreSQL instance is not supported. The settings recommendations that depend on hardware are computed for the whole server, not for one instance, and nothing in Guardioz marks them as such. The index checks are not affected. See Requirements. |
What one collection can carry
Section titled “What one collection can carry”The limits marked per database apply to each database separately; the others apply to the whole instance. The agent records with the snapshot which limit it reached and, except for the session list, the replication slots and the database list, how many objects it left out. An object that was left out is not part of that snapshot, so no check covers it in that snapshot.
No page in Guardioz shows those counts today. The agent writes a line to its log when it reaches the limit on index rows, on databases, on the lists that cover the whole instance and on the size of a snapshot, and writes no line for the other limits. For how to read the log, see Manage the agent service.
One check names the effect of these limits in its finding. Tables behind on cleanup judges a
database only when both its per-table statistics and its table catalog arrived complete. A database
that reached the limit on rows of pg_stat_user_tables, the limit on tables in the daily catalog,
or the limit on one text value is not evaluated by that check. The finding names the database and says that its table statistics or its table
catalog were incomplete. See What Guardioz checks.
The daily catalog and the weekly size pass are the parts the agent collects once a day and once a week. See When the agent collects.
| Limit | Value | What happens at the limit |
|---|---|---|
| Rows of one statistics view, per database | 5 000 | The agent keeps the rows that rank highest for that view: tables by live rows, indexes by number of scans, and the block counters by blocks read from disk. It counts the rows it left out. |
| Tables in the daily catalog, per database | 20 000 | The agent keeps the tables that went longest without vacuum freezing their rows (the oldest transaction-id age), and counts the ones it left out. |
| Tables measured in the weekly size pass, per database | 10 000 | The tables that take the most pages are kept, and the number left out is counted. |
| Index rows, per database | 50 000 | Whole tables are dropped from the end of the list, so this limit never leaves a table with part of its indexes. The agent writes a line about it to its log. |
| Databases per PostgreSQL instance | 20 | The agent collects the per-database data of the first 20 databases by name and leaves the others out of the snapshot, with this line in its log: 25 user databases exceed the limit of 20; monitoring the first 20 by name, 5 left out (with your numbers). The index checks and Tables behind on cleanup do not cover a database that was left out; Tables behind on cleanup names it as not evaluated. The checks that read views of the whole instance still include it: Open transactions and cleanup reports transactions open in it, the work_mem check counts its temporary files, and its replication slots are checked. |
| Sessions in the session list | 1 000 | The agent keeps the sessions with the oldest open transactions. When the list is cut, Guardioz does not run the cleanup checks on that snapshot: Open transactions and cleanup and Tables behind on cleanup. The Findings page then keeps the result of the last snapshot in which they ran. |
| Replication slots | 200 | The agent keeps the slots that hold the most transaction log. When the list is cut, Guardioz does not run the replication slot check on that snapshot. The Findings page then keeps the result of the last snapshot in which it ran. |
| Databases in the database list | 2 000 | The agent keeps the first ones by name. |
| One snapshot | 48 MB | The agent leaves out the weekly size measurements of whole databases and then their daily catalog, starting from the last database by name, until the snapshot fits, and writes Snapshot over 50331648 bytes: relation_sizes of database app left out (with your database) for each. A snapshot that does not fit even then is not sent: Snapshot is ... bytes even without per-database sections; not sent. |
| One text value | 64 KiB | A value larger than that leaves its row out of the snapshot, and the value is never shortened. A value of exactly 64 KiB is kept. This covers the text values of the daily catalog: an index definition, an index expression, the condition of a partial index and the storage options of a table. When a table’s row is left out this way, its index rows are left out with it. An index row left out this way leaves its table without that index. |
Time limits while collecting
Section titled “Time limits while collecting”A measurement that runs out of time is recorded as not measured. Guardioz puts no estimate in its place, and the rest of the collection continues. The exception is the first connection of a collection: when that one fails, the collection ends and no snapshot is sent.
| Limit | Value | What happens at the limit |
|---|---|---|
| Connecting to PostgreSQL | 10 seconds | That connection fails. When it is a connection to one database, the agent writes the reason to its log and records the datasets it could not read. When it is the first connection of the collection, the agent writes the reason to its log and sends no snapshot for that hour. |
| One statement | 30 seconds, and 60 seconds for the size measurements | PostgreSQL stops the statement. In the weekly size measurements the agent then measures the objects one at a time and records only the one that failed as not measured. Any other dataset is recorded as not measured for that database, or for the whole instance. |
| The two statements that run during registration | 10 seconds | These two read the PostgreSQL version and the list of databases. When the version statement runs out of time, Guardioz refuses the server with a message that says it could not read the PostgreSQL version. When the database-list statement runs out of time, the server is registered without its list of databases. |
| Waiting for a lock on a table | 5 seconds | The agent stops waiting. In the weekly size measurements it records that one table as not measured and measures the rest. In the daily catalog, that database is left out of that collection, and its catalog comes with the next daily part. |
| The weekly size measurements in one database | 30 seconds | What was measured is sent, and the rest is recorded as not measured. |
| One operating-system command | 10 seconds | That fact is recorded as not measured. |
| One collection | The collection interval minus 60 seconds | From that point the collection starts no further database: the databases it has not reached are recorded as not collected in that snapshot. The first collection after the installation and a collection started by hand with --once have no such limit. |
| The collection interval | At least 900 seconds | The agent does not start and writes interval is 60 s; the agent runs with at least 900 s. (with your value). The installer sets 3600 seconds, and Guardioz is designed for that value. See Agent configuration. |
Sending a snapshot
Section titled “Sending a snapshot”| Limit | Value | What happens at the limit |
|---|---|---|
| Waiting during one attempt | 30 seconds to connect, and 30 seconds for each wait on the connection | When one runs out, the attempt counts as failed. |
| Attempts per snapshot | Up to 3, with waits of 5 seconds and then 10 seconds | The agent writes Failed to send snapshot after 3 attempts and drops that snapshot. An answer of HTTP 401 or 403 ends it after the first attempt, with Authentication failed (HTTP 401). Check collector_key. An answer of HTTP 409, 413, 422 or 429 also ends it after the first attempt, because sending the same snapshot again cannot change that answer: Cockpit refused the snapshot (HTTP 429): followed by the reason Guardioz gave. After HTTP 503 the agent waits as long as Guardioz asks, at most 60 seconds. |
| Snapshots of one server | One new collection every 10 minutes | Guardioz answers HTTP 429 with A snapshot of this server arrived less than 600 seconds ago. The agent sends one snapshot per collection interval. The scheduled collections are an hour apart, so they meet this limit only when they come less than 10 minutes after a collection started by hand, and that scheduled snapshot is then refused. A collection started by hand with --once within 10 minutes of the previous snapshot is refused: run it again later. A retry of the same collection is not counted. |
| Size of one snapshot that Guardioz accepts | 48 MB | Guardioz answers HTTP 413 before it reads the snapshot. The agent keeps its snapshots within this size itself (the limit on one snapshot, above). |
| Clock of the monitored server | At most 15 minutes ahead of Guardioz, and a collection at most 24 hours old | Guardioz refuses a snapshot whose collection time is more than 15 minutes ahead of its own clock, or more than 24 hours old, with HTTP 422. The agent drops it and writes Cockpit refused the snapshot (HTTP 422): with a reason that asks you to check the clock of the monitored server. |
Nothing is kept on your server for a later attempt. The next collection takes fresh data, and the history in Guardioz has a gap for that hour. The daily and weekly parts are collected again on the next collection. See When the agent collects.
Requests to Guardioz
Section titled “Requests to Guardioz”Guardioz limits how many requests one network address can send in a short time, and it also limits sign-in, password and account-creation requests from all addresses together. The exact numbers are not published. The limits cover signing in, creating an account, asking for a password reset, setting or changing a password, confirming your password before a sensitive action, the endpoints the installer uses, server registrations and snapshots. During a burst of sign-ins from many addresses, a form can be refused even when you submitted it once, and the answer still names your network address. Opening a page in Guardioz is not counted. While the installer runs, the setup page asks Guardioz about its progress, and those requests go to the installer endpoints, which are counted.
Above the limit, the answer is HTTP 429 with this body:
{"detail":"Too many requests from this network address. Wait a minute and try again."}- In a browser, that line is the whole page. Wait a minute, open the page again and repeat what you were doing.
- The installer prints it as
Registration failed (HTTP 429): Too many requests from this network address. Wait a minute and try again.Run the install command again after a minute. When more than 60 minutes have passed, generate a new install command in Guardioz and run that one. See Install the agent. - The agent drops that snapshot after this answer and collects again at its next collection.
Guardioz sends the confirmation link, the password-reset link and the notice that an address already has an account at most once every 3 minutes for one account. The page answers the same whether or not a message was sent.
After 5 incorrect passwords in a row for one account, Guardioz refuses the password of that account for 30 seconds. The time doubles with each further incorrect password, up to 15 minutes. During that time even the correct password is refused, and the sign-in page shows the same message as for a wrong password, with a line that explains the limit:
Incorrect email or passwordAfter 5 incorrect passwords in a row, sign-in with a password pauses for up to 15 minutes. You can reset your password at any time.Wait up to 15 minutes, or reset your password from the sign-in page. A finished reset ends the
wait at once. See Manage your account. Sign-in with Google or
GitHub is not affected. When Guardioz asks for your password again before a sensitive action, or
for your current password when you change it, the same limit applies and the page says
Too many incorrect passwords in a row. Try again in a few minutes (at most 15).
Links, passwords and sessions
Section titled “Links, passwords and sessions”| Limit | Value | What happens at the limit |
|---|---|---|
| Email confirmation link | 48 hours | The page shows Invalid or expired confirmation link. Sign in again to get a new link. |
| Password reset link | 30 minutes | The page shows Invalid or expired reset link. Please request a new one. Ask for a new reset link on the sign-in page. See Manage your account. |
| Password length | At least 8 characters, at most 72 bytes | The form shows Password must be at least 8 characters or Password must be at most 72 characters. The upper limit is counted in bytes, not in characters. A character outside the basic Latin letters takes more than one byte, so a password with such characters can reach the limit before 72 characters. Shorten the password when the form refuses it. |
Guardioz signs you out after a period without activity, and a session also ends when it reaches its maximum lifetime, even while you are working. Shortly before the end of the period without activity, a bar shows Your session expires soon. with a button Extend. Extend does not move the maximum lifetime: when a session reaches it, sign in again. See Manage your account.
Email alerts
Section titled “Email alerts”| Limit | Value | What happens at the limit |
|---|---|---|
| Severity levels that send email | Critical on the Free plan; critical, warning and suggestion on the Team and Scale plans | In Account Settings, Notifications, a level outside the plan is greyed out with the label Team plan and cannot be selected. Guardioz sends no email at that level, also to an account that selected it before; that choice is kept and applies again when the organization moves to a plan that includes the level. See Email alerts. |