# Apify scraper control room your whole team can check

> See every scraper run across your account in one place, catch the ones that finished but came back half empty, and share what happened without extra logins.

- Workflow type: app
- Services: Apify, Google Sheets, Slack Bot
- Categories: Operations, Engineering
- Published: 2026-08-14

## What it does

- Lists every recent scraper run across your whole account with the job name, status, start time, how long it took, how many rows it returned and what it cost, filterable by status and date range.
- Totals the window you pick at a glance: how many runs there were, what share of them failed, and how much you spent.
- Flags runs that report success but returned far fewer rows than that job normally does, and keeps a shared note on each run so whoever investigated can leave a reason the rest of the team can read.
- Opens any run to show its full record, the tail of its log and a preview of the rows it produced, then lets you re-run the job, start a saved configuration, send the rows to a spreadsheet or post a failure summary to Slack.

## What you'll need

- An Apify account and its API token, which you can copy from your Apify settings
- A Google account, if you want to export previewed rows to a spreadsheet tab
- A Slack workspace, if you want to post failure summaries to your engineering channel
- A few past runs already in the account, so the app can work out what a normal row count looks like for each job

## Prompt

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.

## How to customize

- Change how far below normal a run has to fall before it gets flagged, and how many past runs count towards that normal figure
- Set the date range and status filter the main screen opens on, for example last 24 hours, failures only
- Point the spreadsheet export at a specific file and tab, and choose which Slack channel failure summaries go to

## FAQ

### Do my teammates need an Apify login to use this?

No. The app connects once with your Apify credentials, and everyone who can open it sees the same run history. People who never touch the Apify Console can still confirm that last night's data landed.

### How can a run that succeeded still be a problem?

A scraper can finish cleanly and still come back with a fraction of the rows it normally collects, usually because a source changed or blocked it partway through. The app compares each successful run against what that same job usually returns and flags the ones that fall well short, because a quiet partial scrape is the failure people actually miss.

### Can I restart a job from the app?

Yes. From any run you can start the same job again, or pick one of your saved configurations and fire that instead. The new run shows up in the list and you can watch it progress.

### Will it show me why a run failed?

The detail view carries the run's full record along with the tail of its log, which is usually where the error appears. From there you can post a summary to your engineering channel and leave a note on the run explaining what you found.

### Does it track what we are spending on scraping?

Yes. Each run shows its reported cost, and the tiles at the top total the spend across whatever date range and status filter you have applied.

Use this prompt in General Input: https://www.generalinput.com/prompts/apify-scraper-control-room-your-whole-team-can-check