Event Information

Join us for an exclusive look at RaceDay Scoring Version 5, the latest update to RunSignup’s real-time scoring software for today’s timers.

We’ll cover:

•  New Features & Enhancements – Discover key updates designed to streamline scoring workflows.
•  Performance Improvements – Learn how Version 5 boosts speed and accuracy.
•  Expanded Integrations – See how the software works seamlessly with chip timing hardware and RunSignup’s RaceDay tools, including RaceJoy.
•  Live Demo & Q&A – Get a firsthand look at the latest functionality and ask questions along the way.

Join us for this session to help you get the most of the new RaceDay Scoring Version 5!

View Slides 

Summary of Webinar 

The Big Headline: Why V5 Exists

RaceDay Scoring originally relied heavily on:

• JavaScript (single-threaded)

• a browser-based database (prone to corruption)

Matt explained the practical impact in timer terms:

• Single-threaded = “one lane road” → big scoring calculations can block the UI → freezing / unresponsive feel

• Browser DB instability = risk of data issues

What changed in V5

• Core scoring engine rewritten in Rust (compiled, faster, multi-threaded, memory-safe)

• Data storage moved to SQLite (more stable database)

They emphasized: this is a major reliability + scalability step for large events and heavy read processing.

What Timers Should Notice Immediately

V5 is intended to deliver:

• Faster scoring + quicker results, especially large races

• More responsive UI (less/no “locked up” feeling during recalcs or heavy reads)

• Improved reliability (less risk of storage corruption)

• Better scalability (handles more data smoothly)

What’s New in the Product (Features Added Alongside the Rewrite)

1) Real-time Data Checks (big 2025 “real time” push)

Data checks existed before but were “power-user / hidden.” V5 adds:

• Default data checks (templates) to encourage adoption
  Examples mentioned:

  • missing age

  • missing gender

  • “suspicious times” (age grade > 90%, similar to RaceDirector-style suspicious time reporting)

• Dashboard widget showing data checks that currently have matches
  Benefit: you can glance and see “X issues” in real time and click straight in.

• UI improvement: data check filter panel is collapsed by default when viewing an existing check (you see the data first).

Why it matters for timers: faster troubleshooting while the race is happening (catch issues while reads flow in, not after).

2) Raw Reads View Customization (less clutter, faster troubleshooting)

Updates to the Raw Reads view:

• Choose which columns display

• Reorder columns

• Hide fields you don’t use (examples: chip codes, 24h time-of-day, etc.)

• Save your layout as a global default for new races on that computer

Goal: make troubleshooting more efficient by showing only the data you actually need.

3) Participant Filters for Age Groups

New capability: use participant filters in age group logic.

Example given:

• Exclude “elite” participants from age group awards

They framed it as “do anything you want with age groups” using the same filtering style you already use elsewhere.

What’s Coming Soon (Near-Term Roadmap)

Aggregate Team Scoring Improvements

Two big changes:

1. Custom aggregate team scoring rules

   • Support inverted scoring (highest points wins)

   • Support formulas (e.g., points = 10 − place, min 1)

   • Support uploaded point tables (spreadsheet mapping place → points)

   • Edit the table in-app after upload

2. Default reporting changes for aggregate team scoring

   • Previously: often needed two reports (overall + team finisher) → confusing + awkward online results sets

   • New default: one report that supports age groups + team standings together for common setups (e.g., a 5K with one team type)

They noted you’ll still need custom reports for more complex scenarios (multiple team types needing separate breakdowns).

“Realtime Dynamic Adjustments” (very flexible penalties/bonuses)

Concept:

• Apply a defined time adjustment repeatedly based on a numeric field/question.

• Example:

  • “30 seconds off for each donut eaten”

  • “+1 minute penalty per missed obstacle”

Key point: it can sync across tools:

• A check-in app can update the donut/penalty count → syncs through RunSignup → RaceDay Scoring applies adjustments automatically.

More Default Data Checks (and better access)

Planned defaults include:

• missing start read (finish exists but no valid start)

• missing split read / incomplete segments vs expected

• longer-term ideas:

  • show runners where a backup time was selected

  • wave jumper identification (started in a different wave than registered)

Usability updates:

• Add data checks access to the top toolbar (so you can jump to checks from any screen)

• Export/import/print enhancements for data checks

They also mentioned “data issues” is being de-emphasized in favor of the richer data checks approach.

QA + Confidence: How They Tested V5 (and operational readiness)

Sorin shared how they validate releases—especially important because timers don’t get a second chance on race morning:

• A “gold standard” battery of ~30 event scenarios built by Roger Bradshaw (30 years experience), based on real RaceDirector timing history

• Automated regression runs on frequent builds (they ship often, roughly weekly)

• For big releases: full regression deeper testing + additional internal testing by Avery + Sorin

Adoption metrics they shared during the call:

• 210 races have already been scored on V5

• 45 races already set up for the upcoming weekend (at the time of the webinar)

Operational readiness notes:

• Support escalation path to devs

• Ability to deploy fixes quickly if needed (they cited ~15 minutes in emergencies, though they haven’t needed it recently)

Common Questions Answered

“Will upgrading to V5 break anything?”

• They said no major issues upgrading existing races to V5.

• They suggested: upgrade and back up races to the cloud so you can restore if ever needed.

• They noted “downgrading back” could be problematic, but they don’t expect that scenario.

“Do I need new hardware?”

• They indicated no new hardware requirements; existing setups should run better because heavy scoring work is no longer bottlenecked in the browser the same way.

Related Roadmap Items Mentioned Briefly

Series scoring (status)

• Backend syncing and participant merging work largely done (dedupe/merge “Matt” vs “Matthew” type cases)

• Point calculation methods implemented; working on uploading results to series dashboard

• Target mentioned: aiming for May (no hard promise)

“Age group progress” style reporting (future)

• Planned work to show real-time progress of age groups / completion-style reporting (mentioned as upcoming work after some data check additions and more automated testing).