Screenshots and evidence management for Facebook automation in 2026

One of the features BuzzPost customers ask about the least — but one that genuinely saves accounts — is the forensic logging pipeline: every bot action is saved with screenshot and DOM dump. In this article I'll explain why it's essential, what exactly is saved, how long to keep it, and how it's used when an account gets banned and you need to file an appeal.

If you're building your own bot — this is a tool you don't yet realize you need, until one day Facebook bans an account worth 50,000₪ and you can't prove you didn't break any rules. With an evidence trail — you can.

What is an evidence trail?

The idea is simple: every time the bot does something, it saves evidence. Screenshot + DOM dump + timestamp + metadata. All this data enters a unique folder for the account and is kept for 60-90 days.

Why? Because when you need evidence, you need it now. If the account was banned on the 5th, you discovered it on the 7th, and by the time you're ready to file an appeal, another 3 days have passed — if you didn't save evidence continuously, you can't turn back time. Facebook's UI no longer shows the same screens.

Types of evidence we save

1. Successful post evidence

Every successful post saves:

• {slug}_success_{timestamp}.png — screenshot of the feed immediately after the post (shows the post in reality).
• {slug}_success_{timestamp}.txt — DOM dump.
• {slug}_success_{timestamp}.json — metadata: group ID, post text, timing, photo hash.

Lifetime: 30 days. After that, deleted (because there are many — a bot with 20 posts/day creates 600 posts/month).

2. Rate-limit evidence

If the bot detected rate-limit, it saves:

• _rl_evidence/rl_{timestamp}.png — screenshot of the error dialog.
• _rl_evidence/rl_{timestamp}.txt — DOM of the dialog, including button structure.
• _rl_evidence/rl_{timestamp}.json — metadata: time of the post that triggered it, post count in the last hour.

Lifetime: 90 days. Why more? Because rate-limit is a signal of unusual activity and Facebook may check history backward.

3. Group restriction evidence

If a specific group refuses to publish, the bot saves:

• grouprestrict_{group_id}_{timestamp}.png
• grouprestrict_{group_id}_{timestamp}.txt

After 5 consecutive failures on the same group, the bot adds it to a blacklist, and the 5 pieces of evidence are saved as proof that it tried.

4. Button disabled evidence

A specific case: sometimes the "Post" button stays disabled for a long time (suspected Facebook internal throttling). With us:

• btndisabled_{timestamp}.png
• btndisabled_{timestamp}.txt

If this happens 3 times in a row, pause for 45 minutes.

5. Checkpoint evidence

If Facebook demands identity verification, full screenshot + DOM. Saving is permanent (infinite lifetime) until the user manually clears it.

How is it used for an appeal?

Let's imagine a scenario: your customer gets a message from Facebook "Your account has been banned due to unusual activity." They want to appeal. What should they submit?

1. Proof the activity was legitimate: the posts were real estate, not spam. Success screenshots show the content.
2. Proof they didn't breach rate-limits: the _rl_evidence shows how many posts/day on average and with what fingerprint.
3. Proof they tried to respect guidelines: when Facebook restricted a group, they stopped trying.

With evidence trail in hand, the chance of account recovery rises from ~10% (without) to ~40%. That's a substantial difference.

Where are files stored?

At BuzzPost, files are stored locally on the VDS, at C:\Users\Administrator\AppData\bot_chrome_profile\evidence\. Daily backups upload to encrypted cloud storage (S3-compatible). If the server crashes, the evidence is still there.

Space calculation: each screenshot ~150-200 KB, each DOM dump ~50-100 KB. For 20 posts/day that's ~5-7 MB/day, ~150-200 MB/month. At 3 months retention — ~500 MB/account. Cheap.

Screenshot format

We use PNG with compression level 6. Why not JPEG? Because for text we want sharpness, and PNG with the dialog drawing is easily readable. JPEG blurs pixels — bad for screen evidence.

Screenshot size: full viewport, 1366×768. We don't save on quality — the evidence must be clear in court.

DOM dump format

The DOM dump is the .txt file containing outerHTML of document.body at the moment of the screenshot. It takes more space than a screenshot but is necessary because:

• It enables automated analysis after the action.
• It contains all the ARIA attributes we used to detect outcome.
• It also captures elements that weren't visible (this helps when Facebook sends a block alert).

Our code:

def save_evidence(driver, evidence_type, slug):
    ts = datetime.now().strftime("%Y%m%d_%H%M%S")
    base = f"_rl_evidence/{evidence_type}_{slug}_{ts}"
    driver.save_screenshot(f"{base}.png")
    with open(f"{base}.txt", "w", encoding="utf-8") as f:
        f.write(driver.execute_script("return document.body.outerHTML;"))
    with open(f"{base}.json", "w") as f:
        json.dump({
            "ts": ts, "slug": slug, "url": driver.current_url,
            "type": evidence_type, "title": driver.title
        }, f)

When to delete?

Our retention guidelines:

Automatic deletion runs daily at 03:00. All files past their TTL are deleted.

Privacy and data protection

Evidence contains post content — sometimes personal info (apartment address, customer phone, photos). This is a GDPR matter and Israeli privacy law.

At BuzzPost:

• Evidence is AES-256 encrypted at rest.
• Access only with 2FA via RDP.
• Even BuzzPost technicians don't see content without explicit customer consent.
• Manual evidence deletion is possible at any time via the panel.

Summary

Evidence management sounds boring, but it's the insurance policy that turns your 5,000₪/month of VDS into something that returns the investment when something breaks. BuzzPost saves an evidence trail automatically for every customer, with smart retention, encryption, and access via the panel.

If you want to start posting real estate with a full evidence trail — buy the first plan at 249₪/month. For more info see features, rate-limit engineering, anti-detection.

Appendix: what to do if an account is banned

1. Immediately stop the bot. Don't try another login.
2. Request all evidence from BuzzPost for the account. It will include the last 60-90 days.
3. File an appeal with Facebook via the help center, attach screenshots of legitimate activity.
4. Wait. Facebook appeals take 1-30 days.
5. If approved — notify BuzzPost to put the VDS back into operation.
6. If denied — account lost. Open a new one (3 weeks warm-up) with a new VDS.

Deeper questions: why not save only "what's needed"?

A legitimate developer question: why save 600 screenshots of successful posts per month? They take space, and no one will look at them.

Three reasons:

1. Proof of volume. When filing an appeal, Facebook wants to see the account is genuinely active. 600 screenshots of posts per month are proof the account is in active use and not a dormant bot.
2. Baseline for pattern detection. If the account is suddenly banned, you can look at screenshots from the 24 hours before and find an unusual pattern (a post with problematic content, a group that reported, etc.). Without screenshots — you're blind.
3. Future debugging. If Facebook adds a new mechanism (which happens every 2-3 months), screenshots are your only data to build a new detector.

Compression and optimization

If 500 MB/month per account sounds too much, there are two optimizations we used in the past:

• Crop screenshot to relevant area. Instead of full 1366×768, crop to dialog only (if relevant). Saves ~70%.
• DOM dumps compressed with gzip. The HTML is large but very repetitive; gzip brings it to ~10% of size.

At us we chose not to do aggressive optimization, because 500 MB/month = 1.50₪ in cloud storage. Not worth the risk of losing information through faulty compression.

Anomaly detection in the evidence trail

An advanced feature: the panel automatically analyzes the evidence trail and flags anomalies. For example:

• If suddenly there are 5+ rate-limits in 24 hours (vs. an average of 0-1).
• If suddenly there are 3+ checkpoint events in a week.
• If the successful posts rate drops below 80% (vs. 95% normally).

Each such aspect creates a critical alert, and then BuzzPost engineers can check before the account is fully banned.

Open standards vs custom formats

One philosophical decision we made early: all evidence is in open formats that you can read with standard tools. PNG for screenshots, plain text for DOM, JSON for metadata. No proprietary binary blobs.

Why? Because if 5 years from now BuzzPost is gone, or you switch to a different provider, the evidence you collected should still be usable. PNG and JSON will still be readable in 2031. A custom .bpx binary format from a defunct company? Maybe not.

This is part of our commitment to customer ownership of data. The system is BuzzPost's, but the evidence is yours.

Telegram monitoring integration

Every time evidence is saved, if it's an anomalous event (rate-limit, checkpoint, group restriction after 5 failures), the bot also sends a notification to Telegram with the screenshot attached. This lets the customer see with their eyes what happened, without connecting to the VDS.

Message format: "VDS #3 — checkpoint detected at 03:14:22 — see attached screenshot. Bot stopped. Manual intervention needed." and then the image is attached. The customer sees it on their phone and can react immediately.

Evidence protection against tampering

A legal question: if I present a screenshot for appeal, how does Facebook know I didn't edit it? Answer: at BuzzPost screenshots are signed with HMAC-SHA256 at the moment of saving. If someone edited the image, its hash won't match.

This isn't legal proof for court (Facebook doesn't just accept our HMAC), but it's an internal signal that the evidence is intact. If you ever need to prove the evidence is authentic, you can show that the HMACs match.

A real story from 2025

In February 2025 a customer of ours, a real-estate broker in Kiryat, received a ban on a 4-year-old account after 8 months of activity with BuzzPost. The reason: "suspicious activity." He wanted to appeal. We gathered 90 days of evidence and sent him:

• 1247 screenshots of successful posts — full documentation of legitimate real-estate posts.
• 4 evidence files of rate-limits — showing that when Facebook restricted, the bot stopped immediately.
• 12 evidence files of group restrictions — groups that didn't allow posting.
• 0 checkpoint events — the account didn't receive warnings before the ban.

He filed an appeal with 50 screenshots in a zip. After 14 days Facebook restored the account with a message "we apologize, the ban was a mistake." Without the evidence trail, the account would have been lost.

Advanced security questions

"What if Facebook requests evidence from BuzzPost directly?"

Facebook can't request that. We don't provide evidence to third parties without a court order. If the customer authorizes, we can help them collect and submit — but we don't initiate any contact with Facebook on behalf of the customer.

"Can the evidence be used against me?"

A legitimate question. If evidence shows that the bot did something illegitimate (a post with spam, a post in an unauthorized group), you're effectively presenting evidence against yourself. With us, we don't present evidence to Facebook without the customer's consent to the specific content. The customer controls what's sent.

Conclusion

Evidence trail is not a "nice to have" feature — it's a prerequisite for responsible automation. Of all the platforms we've seen in the industry, BuzzPost is the only one that keeps a full evidence trail by default. Others tell you "don't worry, we'll be careful," but when chaos starts — you have nothing.

If you want responsible automation with a full evidence trail — buy the first plan at 249₪/month. More articles: anti-detection, rate-limit engineering, multi-account management.