A scraping job can fail for many reasons. The target page may block the request. The request options may be wrong. The account may have no credits. The service connection may also be unavailable for a short time. A simple status check helps you separate these cases.
The ScraperFly status API URL is a lightweight health check. Your system can call it on a schedule, store the result, and build a small history of service availability and response time.
This page explains a simple way to use the status check. The goal is not to replace request logs. The goal is to add one clear signal: can your system reach ScraperFly right now, and how fast does the check answer?
What the status API URL is for
The status API URL is a small service check. It tells your application whether ScraperFly can be reached from the place where your own jobs run. If the check answers with a healthy result, your application knows that the basic service path is working.
This does not mean every scrape will succeed. A healthy service check does not fix a bad URL, a blocked target page, a wrong API key, a missing credit balance, or a page that needs JavaScript rendering. It only answers one simple question: is the ScraperFly service reachable right now?
How to check service health every few minutes
A practical monitor can call the status API URL every five minutes. For each check, store the time, the HTTP result, and the response time. This gives your team a simple view of availability over time.
Do not alert on one slow or failed sample too quickly. Networks can have short delays. A better monitor waits for repeated failures or a clear pattern of slow response times before sending an alert.
| Value to store | Why it helps |
|---|---|
| HTTP result | Shows whether the status check answered successfully. |
| Response time | Shows how long the service check took from your environment. |
| Check time | Shows when the sample was collected. |
| Failure count | Helps avoid noisy alerts from one short network issue. |
Example status log
A small table is enough for many teams. You can keep the last few hours or days of checks and show them in an internal dashboard. The table below is only an example of the kind of data you may store.
| Time | Check URL | Result | Response time | Note |
|---|---|---|---|---|
| 09:00 | /api/v1/status | 200 OK | 142 ms | Service check passed. |
| 09:05 | /api/v1/status | 200 OK | 156 ms | Service check passed. |
| 09:10 | /api/v1/status | 200 OK | 149 ms | Service check passed. |
How to read status together with request logs
Use the status check together with normal scraping logs. If the service check is healthy but a scrape fails, look at the request itself: target URL, target status code, final URL, response size, output format, rendering option, retry history, and account state.
If the service check fails many times in a row, treat that as a service connectivity signal. Pause noisy retries, keep the failed jobs in a queue, and retry them after the health check is stable again.
What the status check does not prove
The status check is not a guarantee that a target website will return usable data. It does not test your target URL. It does not confirm that a page allows access. It does not confirm that JavaScript rendering is needed. It also does not replace account, billing, or request-level diagnostics.
Think of it as one small operational signal. It helps answer whether ScraperFly is reachable. After that, your request logs explain what happened with each scraping request.
FAQ
How often should I call the ScraperFly status API URL?
For a small health monitor, checking every five minutes is usually enough. You can use a shorter interval if your own system needs faster alerts.
Does a healthy status check mean every scraping request will work?
No. A healthy status check only means the service can be reached. Target errors, wrong request options, account issues, rate limits, and access blocks still need request-level diagnostics.
Should I stop all scraping jobs after one failed status check?
Usually no. One failed check can be a short network issue. It is better to wait for repeated failures before pausing jobs or sending an alert.