Skip to content
Pilot RD onboarding kit · operator-facing

Day-of-Event Runbook

Race-day is the moment of truth. This doc tells you what to keep an eye on, when to call us, and how to recognize the common failure shapes early enough to fix them mid-event.

Keep this open on your phone or tablet during the event. If you're delegating monitoring to an ops lead, give them the link.

The 90-second pre-race check

About 90 minutes before gun time, do this once:

  • Public event page loads from your phone on cellular (not just your office wifi).
  • At least one photographer is logged into the photographer app and can confirm they can take a test photo + see it in their queue.
  • Your support email is on your phone (not just your laptop).
  • You have the founder mobile (sent at kick-off) saved as a contact, not a number you have to look up.

If any of the above fails, text the founder mobile now — not after the gun.

What to monitor during the event

Photo upload velocity

The single most useful number on race day. As photographers shoot, photos should flow into the system in a steady stream — not a giant batch at the end.

  • Where to watch: your org admin → "Live coverage" panel on the event page. (If the realtime coverage stream isn't fully shipped at your pilot date, we'll send you a refreshable URL or a Grafana view.)
  • Healthy: photos arrive within minutes of being taken. The matching pipeline tags them with bib + face within another 1-3 minutes.
  • Watch for: a photographer whose upload counter is flat-lining while others climb. Usually a wifi/cellular issue at their station, not a system issue. Text them first.

Athlete claim queue

As athletes finish, they start landing on the event page looking for their photos. The matching pipeline should be ahead of them — most athletes find at least one of their photos on first visit.

  • Healthy: "Photos found" hit rate visible on the admin dashboard climbs above ~70% within the first hour after each wave.
  • Watch for: a sustained dip below 50%. Usually means a photographer's photos haven't uploaded, OR a bib range is wrong in the event config.

Checkout health

The thing that turns this into a business.

  • Where to watch: admin → "Sales" panel. Counter climbs as orders flow in.
  • Watch for: a sudden zero. If five minutes go by with photos being viewed but no sales, something is wrong with checkout. Escalate fast — every minute of broken checkout during peak is a lot of lost revenue.

Active dashboards (operator-curated)

These dashboards are live in our Grafana org. Viewer access is provisioned for you at pilot kickoff; the URLs above will load once your account is added. If they 404 or prompt for login during your event, text the founder mobile — that's a P0 on our end to fix.

Escalation: what's a P0 vs P1

P0 — call the founder mobile (the number sent at kick-off)

Real-time response. These are the only things that should trigger a phone call:

  • No photos uploading from anyone for 10+ minutes during active race window
  • Checkout completely broken (multiple athletes reporting "can't pay", or sales counter zero during peak)
  • Mass athlete complaints (your inbox or Twitter mentions lighting up — typically means something visibly broken on the public page)
  • Payouts visibly wrong during the event itself (rare; usually surfaces post-event in reconciliation, but if a photographer flags a wildly wrong number to you in real time, escalate)
  • Suspected data leak (athlete A sees athlete B's order or PII — drop everything and call)

P1 — email support@podiumbase.io, expect 4-hour response during event window

Important but not race-killing:

  • Single-athlete dispute ("I can't find my photos", "I was charged twice")
  • One slow photographer (rest of roster uploading normally)
  • Single photo flagged inappropriate / wrong athlete tagged
  • Brand kit displaying wrong sponsor
  • Refund request that needs founder review

Not an escalation at all

These are normal — note them down for the debrief, but don't message us mid-race:

  • One athlete who didn't find themselves and emails the next day (could be a real bib match issue, could be they never had their bib visible — investigate after)
  • Small UI quirks that don't block a transaction
  • Photographer asking about their share / payout (the dashboard answers this; they should ask their org admin first)

Common runtime issues + first-pass fixes

"A photographer says they uploaded but nothing's in the gallery"

  1. Ask them to check their photographer app's upload queue — is it stuck or actively retrying?
  2. If retrying: it's a connectivity issue at their station. Move them to better signal, or have them switch to a hotspot.
  3. If queue says "uploaded" but gallery is empty: this is on us. Escalate to founder mobile.

"An athlete can't find their photos"

  1. Ask for their bib number.
  2. Search the event admin → search bar → enter bib.
  3. If photos exist but didn't surface for them: usually a bib-visibility issue (turned around, occluded, blurred). Photos can be claimed by face match — ask the athlete to also upload a selfie via the "Help me find my photos" flow.
  4. If no photos at all under that bib: confirm they were in the event (check registration), then check whether any photographer covered their section of the course at their estimated time.

"Checkout returned an error"

  1. Get a screenshot from the athlete if possible — Stripe error messages are usually informative.
  2. Most common: bank-issued decline. Athlete tries a different card → works.
  3. If multiple athletes report the same error in a short window: escalate to founder mobile, this is a checkout-side issue.

"Refund requested by an athlete"

  1. Confirm the order ID (from their confirmation email).
  2. Issue refund via admin order page. Refund hits the athlete's card in 5-10 business days (their bank's timing, not ours).
  3. For disputed cases ("photo doesn't match" / "didn't authorize"): forward to support, don't auto-refund.

For the canonical incident-response runbooks (the ones we use on our side), see the Module 1.6 runbook — covers refund handling, dispute resolution, sponsor billing edge cases, and the canonical kill-switches the operator can pull during a live event.

Mid-event communication pattern

  • Status check from founder side: we'll text you once at race start ("we're watching") and once mid-race ("everything looks normal from our side"). If you don't hear from us by 30 min after gun time, text us.
  • Status check from your side: every couple of hours, glance at the dashboards. If you see a number going the wrong direction, message support — even if it's not a P0. Better to flag early.
  • End-of-event: text us when the last wave is in and your photographers have stopped uploading. We'll do a quick eyeball on the numbers and confirm the event looks healthy before we both go decompress.

Next: within a week, work through post-event reconciliation.

Day-of-event runbook · PodiumBase pilot RD kit