Apify scraper control room your whole team can check

Build me a control room for everything our scrapers do, so the team can tell whether last night's data actually landed without anyone needing an Apify login. It should be a monitoring app people open in the morning, not something that runs on a schedule.

The main screen is a table of every recent run across the whole account, loaded with the Apify List User Runs operation and sorted newest first. Each row shows the Actor name, the run status, the start time, the duration, the number of items the run produced, and the reported usage cost. Give me two filters above the table: status (READY, RUNNING, SUCCEEDED, FAILED, ABORTED, TIMED-OUT) and a date range, defaulting to the last 7 days. Both filters drive everything else on the screen.

Above the table put three summary tiles for the selected window: total runs, failure rate as a percentage, and total spend. Recompute them whenever the filters change, and make it obvious that they describe the filtered window rather than all time.

The nuance that makes this app earn its place: flag runs that finished SUCCEEDED but returned far fewer items than that Actor's recent average. A silent partial scrape is the failure people actually miss, because the status says everything is fine. Build a per-Actor baseline from that Actor's recent successful runs (group the account-wide run list by Actor, or call List Actor Runs per Actor) and flag any SUCCEEDED run whose item count falls below a configurable share of that baseline. Default to flagging below 60 percent of the median of the last 10 successful runs, and require at least 3 prior successful runs before a baseline is considered meaningful. Render the flag as its own warning state, visually distinct from a real failure, show the comparison inline (for example "412 items, normally about 1,900"), and let people filter the table down to flagged runs only.

Selecting a run opens a detail pane with three sections. First, the full record from Get Actor Run: status, exit reason, start and finish times, duration, item count, usage cost, the cost controls that were in effect (memory, timeout, maxItems, maxTotalChargeUsd) and the storage IDs, including defaultDatasetId and defaultKeyValueStoreId. Second, the tail of the log from Get Run Log, showing roughly the last 200 lines in a monospace scrollable block, since the error is almost always at the bottom. Third, a preview table of the rows the run actually produced, read with Get Dataset Items against the run's defaultDatasetId, showing the first 50 rows with columns derived from the keys present in the returned objects. Note for whoever builds this: the dataset items endpoint returns the array directly rather than the usual { data: ... } envelope, and pagination state comes back in the X-Apify-Pagination-* response headers.

From the detail pane I need four actions. Re-run the job with Run Actor (Async), reusing the same Actor and input as the run I am looking at, so a failed scrape can be kicked off again in one click. Pick a saved configuration from List Actor Tasks and fire it with Run Task (Async), presented as a picker of the account's tasks. Export the previewed rows to a spreadsheet tab with Google Sheets Append Values, letting me choose the spreadsheet and tab and writing a header row plus the previewed rows. Post a failure summary to the engineering channel with the Slack Bot Send a Message operation, pre-filling the message with the Actor name, status, start time, duration, item count against the normal figure, an excerpt of the log tail, and a link back to the run. Let me edit the message before it sends and pick the channel.

After firing a run with either Run Actor (Async) or Run Task (Async), show the new run ID immediately and refresh the list so the run appears with a RUNNING status that people can watch.

Keep a per-run note field so whoever investigated can leave a reason the rest of the team can read. Store notes in the app's own storage keyed by run ID, since Apify has nowhere to put them. Record who wrote each note and when, make notes editable, show them to everyone who opens the app rather than keeping them private per user, and put a small indicator on rows in the main table that already carry a note so nobody re-investigates something a colleague already explained.

Handle the ordinary states properly: a loading state on the table and each detail section, an empty state when the filters match nothing, and a readable error if Apify rejects the credentials or rate limits us. Remember that only SUCCEEDED means the dataset is trustworthy, and even then it can be partial, which is exactly what the flag exists to catch.