Play Fest Guide: Win Big with Epic Prizes, Gaming Leagues, and Daily Deals Starting October 13

Play Fest Guide: Win Big with Epic Prizes, Gaming Leagues, and Daily Deals Starting October 13

Google Play's Play Fest is framed around three promises: epic prizes, gaming leagues, and daily deals, with the event starting October 13. That framing comes directly from the announcement published on the Google blog, and it is the entire verified surface we have to work with here.

So this guide does two things. First, it separates what the announcement actually establishes from what people will inevitably assume about it. Second, and more usefully for anyone who builds things, it walks through a real, runnable monitoring setup: a small Python watcher that polls the official Play Fest page, detects changes, and pings you when something new appears — instead of you refreshing a browser tab every morning for the length of the promotion.

That is the honest version of a "Play Fest guide" written for a technical audience. We cannot responsibly describe prize tiers, league brackets, or discount percentages that the source does not state. We can build tooling that surfaces those details the moment the official page publishes them.

What the Source Actually Verifies

The available source is the Google blog announcement at https://blog.google/products-and-platforms/platforms/google-play/play-fest. From it, the following is established:

• Play Fest is a Google Play event.
• It involves prizes, gaming leagues, and daily deals.
• It starts October 13.
• The announcement is timestamped 2026-10-08T15:30:00.000Z in the source record we were given, which places it roughly a week ahead of the October 13 start.

Everything beyond that line is interpretation, and it is worth listing explicitly because event coverage tends to fill gaps with plausible-sounding invention.

Not verified by the supplied source: the monetary value or number of prizes; how winners are selected; which countries or accounts are eligible; whether the gaming leagues are first-party Google Play competitions, publisher-run tournaments, or community leagues; how large the daily deals are or how often they rotate; the end date of the event; whether participation requires a specific app version, a Google account in good standing, or a Play Points balance.

Any article that hands you those numbers without a citation is guessing. Treat them as unknown until the official page states them.

Why the Practical Move Is Tooling, Not Hype

An event built around daily deals has a structural property: its content changes on a cadence you do not control. Manually checking a landing page once a day is fine for a week. It becomes friction immediately after that, and friction is where people miss things.

A scheduled watcher solves this with a small amount of code and no ongoing attention. It also happens to be the polite way to monitor a public page: one request every few hours, with an honest User-Agent, rather than a browser tab polling aggressively in the background.

The design below is deliberately generic. It works for the Play Fest announcement page, for any RSS feed a publisher offers, and for the store listings you care about. Nothing in it depends on a private API, and it makes no assumption about what the Play Fest page will contain.

Architecture: Five Moving Parts

Keeping the pieces separate makes the system easy to debug when a page changes its markup or a request starts failing.

1. A source list — a YAML file naming what to watch and how to treat it (HTML page or RSS feed).
2. A fetcher — requests for pages, feedparser for feeds.
3. A state store — a JSON file holding a SHA-256 digest of the last successful fetch, per URL.
4. A report layer — a clear log line plus a meaningful exit code, so cron or CI can decide whether to alert.
5. A scheduler — cron, a systemd timer, or GitHub Actions.

Because the state store is just a hash, the watcher never needs to keep copies of Google's content. It only needs to know whether the bytes it received are identical to the bytes it received last time.

Requirements

You need a machine you control — Linux, macOS, or Windows with WSL — and the following:

• Python 3.10 or newer.
• git (optional, but useful for keeping the config under version control).
• A scheduler: cron, systemd, or a GitHub repository with Actions enabled.
• Optional: Docker, if you would rather not install Python packages on the host.
• Optional: an outbound webhook URL for notifications.

Confirm the basics before installing anything.

This checks your Python version; you want 3.10 or higher for the type hints used in the script.

python3 --version

This confirms curl is available for the manual notification examples later.

curl --version

This confirms git, which you only need if you plan to version the configuration.

git --version

Step-by-Step Installation

1. Create the project directory and a virtual environment

A virtual environment keeps these packages isolated from your system Python.

mkdir -p ~/playfest-watch && cd ~/playfest-watch
python3 -m venv .venv
source .venv/bin/activate

On Windows with PowerShell, the activation line is .venv\Scripts\Activate.ps1 instead.

2. Install the dependencies

Upgrade pip first, then install the four libraries the watcher needs: requests for HTTP, beautifulsoup4 for HTML parsing when you want it, feedparser for RSS, and PyYAML for the config file.

python -m pip install --upgrade pip
pip install requests beautifulsoup4 feedparser pyyaml python-dotenv

Freeze the exact versions so the schedule keeps working after an unattended upgrade.

pip freeze > requirements.txt

3. Create the source configuration

This file lists what to watch. The Play Fest announcement is the first entry; add more sources as you find feeds worth tracking.

# sources.yml
sources:
  - label: "Google Play — Play Fest announcement"
    url: "https://blog.google/products-and-platforms/platforms/google-play/play-fest"
    kind: page

4. Write the watcher

Save this as watch.py. It fetches each source, hashes the result, compares against the stored digest, and returns exit code 2 when something changed — which is what a scheduler uses to decide whether to notify you.

"""Poll public pages and feeds, and report what changed since the last run."""
from __future__ import annotations

import hashlib
import json
import pathlib
import sys
import time

import feedparser
import requests
import yaml

USER_AGENT = "playfest-watch/1.0 (personal monitoring; contact: you@example.com)"
STATE_FILE = pathlib.Path("state.json")
TIMEOUT = 20


def load_sources(path: str = "sources.yml") -> list[dict]:
    with open(path, "r", encoding="utf-8") as handle:
        return yaml.safe_load(handle)["sources"]


def load_state() -> dict:
    if STATE_FILE.exists():
        return json.loads(STATE_FILE.read_text(encoding="utf-8"))
    return {}


def save_state(state: dict) -> None:
    STATE_FILE.write_text(json.dumps(state, indent=2, sort_keys=True), encoding="utf-8")


def fetch(url: str) -> str:
    response = requests.get(url, headers={"User-Agent": USER_AGENT}, timeout=TIMEOUT)
    response.raise_for_status()
    return response.text


def digest(text: str) -> str:
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


def main() -> int:
    state = load_state()
    changed: list[tuple[str, str]] = []

    for source in load_sources():
        url = source["url"]
        label = source.get("label", url)
        try:
            if source.get("kind") == "feed":
                parsed = feedparser.parse(url)
                entries = [
                    (entry.get("id") or entry.get("link", ""), entry.get("title", ""))
                    for entry in parsed.entries
                ]
                payload = json.dumps(entries, sort_keys=True)
            else:
                payload = fetch(url)
        except Exception as exc:  # network errors should not kill the run
            print(f"[warn] {label}: {exc}", file=sys.stderr)
            continue

        current = digest(payload)
        previous = state.get(url, {}).get("digest")

        if previous and previous != current:
            changed.append((url, label))

        state[url] = {
            "digest": current,
            "label": label,
            "checked_at": int(time.time()),
        }

    save_state(state)

    if changed:
        for url, label in changed:
            print(f"[changed] {label} -> {url}")
        return 2

    print("[ok] no changes detected")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

5. Run it once to seed the state file

The first run always reports "no changes," because there is nothing to compare against yet.

python watch.py

You should see [ok] no changes detected and a new state.json in the directory. Keep that file out of version control if you commit the project.

printf 'state.json\n.env\nwatch.log\n' >> .gitignore

6. Establish a configuration baseline

If you want notification credentials later, store them in a .env file rather than in the script.

printf 'WEBHOOK_URL=%s\n' 'your-webhook-url-here' > .env

Usage Examples

Example 1: Interpret the exit codes

The script communicates through its exit status, which makes it composable with anything.

python watch.py
echo "exit code: $?"

A 0 means nothing changed. A 2 means at least one source changed and you probably want to look. Any other non-zero value means an unexpected error worth investigating.

Example 2: Compare two snapshots directly

When you want to know what changed rather than that something changed, fetch the page twice with a manual copy in between.

curl -sS -A "playfest-watch/1.0" -o before.html \
  "https://blog.google/products-and-platforms/platforms/google-play/play-fest"

Wait a few hours, then fetch again with the same command but writing to after.html. Then diff them.

diff -u before.html after.html | head -n 80

Because modern pages are generated dynamically, a raw diff will contain markup noise. Strip tags first for a cleaner comparison using a short Python one-liner.

python -c "import sys,re,pathlib; t=pathlib.Path('after.html').read_text(errors='ignore'); print(re.sub(r'<[^>]+>',' ',t))" | tr -s ' ' > after.txt

Example 3: Prioritize the parts you care about

Daily deals are only interesting if they touch something you actually want. This filter scans fetched text for the event's own vocabulary and prints the keywords it finds.

KEYWORDS = ("prize", "league", "deal", "daily", "reward", "play fest")

def hits(text: str) -> list[str]:
    lowered = text.lower()
    return sorted({word for word in KEYWORDS if word in lowered})

Run it against the fetched page and log the result alongside the digest. Over a few days you will see which terms appear and disappear — a cheap signal about how the promotion is rotating.

Example 4: Send a notification when something changes

A webhook POST is the smallest useful alert. Wire it to the 2 exit code from the watcher.

if [ "$(python watch.py > /dev/null; echo $?)" = "2" ]; then
  curl -sS -X POST "$WEBHOOK_URL" \
    -H "Content-Type: application/json" \
    -d '{"text":"Play Fest page changed — check https://blog.google/products-and-platforms/platforms/google-play/play-fest"}'
fi

Example 5: Test the pipeline against a local server

Point the watcher at a local file server to prove the diff logic works without touching a live site.

python -m http.server 8000 --directory ./fixtures

Then temporarily set a source URL to http://localhost:8000/index.html, run the watcher twice, edit the fixture file in between, and confirm the second run exits with code 2.

Example 6: Run without installing anything

If you would rather keep the host clean, the same script runs in a container.

docker run --rm -v "$PWD":/app -w /app python:3.12-slim \
  sh -c "pip install -q -r requirements.txt && python watch.py"

Scheduling the Watcher

With cron

This checks every six hours — four requests a day to a public page, which is courteous and sufficient for a promotion that updates daily.

crontab -e

Add a single line, adjusting the paths to your home directory.

0 */6 * * * cd /home/you/playfest-watch && /home/you/playfest-watch/.venv/bin/python watch.py >> watch.log 2>&1

With GitHub Actions

If you would rather not maintain a server, a scheduled workflow does the same thing. Note that the state file must be cached between runs, otherwise every run looks like a first run.

name: playfest-watch
on:
  schedule:
    - cron: "0 */6 * * *"
  workflow_dispatch:

jobs:
  poll:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: python watch.py

Operational and Ethical Guardrails

Automation around someone else's event page has limits, and respecting them keeps the tool usable.

• Read `robots.txt` before you scale up. If the path is disallowed, do not poll it.
• Send an honest User-Agent with contact information. Anonymous, high-frequency scrapers get blocked, and rightly so.
• Never scrape behind authentication. Your Google account session is not a data source, and automating it likely violates the terms you agreed to.
• Rate-limit yourself. Four requests a day is monitoring. Four hundred is abuse.
• Keep notifications human-readable. An alert that says "something changed" without a link is noise.

Limitations and Open Questions

This guide is built on a single source, and that constrains what it can claim. The announcement establishes that Play Fest features prizes, gaming leagues, and daily deals starting October 13. It does not establish prize structures, league formats, regional availability, deal magnitudes, or an end date — and no amount of tooling changes that. The watcher does not create information; it just shortens the gap between publication and your awareness.

There is also a practical limit to hash-based detection. A page that rotates a promotional banner or injects a session token will produce a different digest on every fetch, generating false positives. If that happens, switch the source to an RSS feed (set kind: feed) or filter the HTML before hashing so that volatile fragments are excluded. The architecture supports both without a rewrite.

Conclusion

Play Fest runs on a daily cadence, which is exactly the kind of schedule humans are bad at tracking and machines are good at. The verified core is short — prizes, gaming leagues, daily deals, starting October 13 — so the sensible response is not to speculate about what those details will be, but to build a small, polite watcher that tells you the moment they are published.

Everything above runs on a laptop, a spare VM, or a free CI runner, and costs one YAML file, one Python script, and a scheduled command. Set it up before October 13, seed the state file, and let the exit codes do the remembering. When the first real detail lands on the official page, you will know within six hours — and you will know it is real, because you read it at the source rather than in a summary.