Limits

Pharos caps the size of a request and the reach of a listing, so that one caller cannot ask for an unbounded amount of work. The caps are generous for normal use and are the same whether a request comes from the console or from a script. This page collects the ones a reader is most likely to meet.

Result pages

A listing returns at most 100 rows per page. The count shown above a table is the true total that matched, not the size of the page, so a table reading "200 of 61,592" has matched 61,592 records and is showing one page of them.

A listing pages to a depth of 100,000 rows. Reaching further is refused rather than served slowly, because an answer that deep is a query that should be narrowed with a filter or a search term instead.

The vendor, product and package tabs page like the CVE list, with the true total under the table. Asked without a page, the same lists return a ranked slice instead, the most affected first, capped at 1,000 entries, with the true total beside it.

Investigate

A single lookup on the Investigate page checks at most 1,000 values. A paste larger than that is refused with the count it saw, rather than being silently truncated to the first thousand. Investigate is a read and is never billed, so the cap is about the work of one request, not the bill.

Request size and destinations

A request body is at most 5 MiB. An email notification channel delivers to at most 20 recipients. Both are refused with a message naming the limit rather than being trimmed.

Under load

A query that asks for too much can time out. Narrowing it with a filter or a search term is the fix, since a query that reads less also returns sooner.

The service also limits how fast requests may arrive. A caller sending too many too quickly has a request rejected until the rate falls, which a script should handle by pausing and retrying. Neither of these is an error in the workspace or the data.