Query “JRF”, related to the Jakarta Running Festival 2026, was recorded as active on Google Trends Indonesia in the morning of October 24, 2026. Upon review, the query exceeded 2,000 searches and rose by about 100% compared to its normal level in the Google Trends snapshot. Google Trends
The surge in searches coincided with the Jakarta Running Festival series held from October 22–25, 2026 at the Gelora Bung Karno area, Jakarta. The official site lists several race categories, including Half Marathon and 5K on October 24 and Marathon and 10K on October 25. World Athletics also lists the JRF Half Marathon on October 24 and the JRF Marathon on October 25 in the Road Races Label calendar. jakartarunningfestival.id
Trend data only shows an increase in search interest, not its cause. This article is also not an audit of the Jakarta Running Festival system. JRF is used as a current context to discuss the challenges when thousands of people access information, register, pay, receive tickets, and check in within a close time frame.
For event businesses, the question isn’t just “can the website open?” The digital event system must be able to maintain quotas, prevent double transactions, validate tickets, deliver timely information, and provide operational insight to the committee.
Here are seven foundations that need to be prepared.
1. Fast: Information and Registration Pages Must Be Responsive
Interest spikes usually first enter through the information page. Visitors want to know the schedule, location, category, price, facilities, rules, and registration button without waiting for a heavy page.
Google via web.dev uses three Core Web Vitals to assess page experience: Largest Contentful Paint for the speed of main content display, Cumulative Layout Shift for visual stability, and Interaction to Next Paint for responsiveness to user interaction.
For event organizers, this principle can be applied with:
- Compressing images and using modern formats.
- Avoiding large auto‑play videos on the registration path.
- Loading third‑party scripts only when needed.
- Displaying core information before decorative elements.
- Testing the page on mobile networks, not just office Wi‑Fi.
- Using cache and content delivery networks.
- Providing a status page when core services are disrupted.
Speed also needs to be tested under busy conditions. Load testing should simulate real patterns: many people opening the same category, filling forms, checking quotas, and pressing the payment button at close times.
Minimum control: monitor response time, error rate, and service capacity before registration opens and during peak periods.
2. Quota: Use a Single Data Source and Temporary Reservations
The common issue in event systems is a quota that appears available to two users at the same time.
If the process only reads the quota number and then subtracts it after payment, the system can sell tickets beyond capacity.
Use one primary data source for availability. When a participant selects a category, the system can create a temporary reservation with an expiration time. The quota is confirmed after successful payment and released again if payment does not complete.
Data that needs to be distinguished:
- Total quota.
- Available quota.
- Quota currently reserved.
- Payment pending.
- Ticket issued.
- Cancellation or refund.
- Quota intentionally held by the committee.
Every change must be consistent and traceable. Do not rely on separate spreadsheets for the public page, payment, and operations team because differing update times can cause conflicts.
Minimum control: a single participant cannot reduce the quota twice due to a button re‑press, page reload, or duplicate payment notification.
3. Pay: Separate Order Status from Payment Status
Creating an order does not mean payment has succeeded. The event system needs to separate statuses such as:
- Form started.
- Order created.
- Awaiting payment.
- Payment confirmed.
- Payment expired.
- Failed.
- Cancelled.
- Refund processed.
- Refund completed.
Use a unique reference number and process payment notifications idempotently. In other words, the same notification can be received multiple times without issuing two tickets or reducing the quota twice.
For card payments, the PCI Security Standards Council emphasizes payment data protection and the use of validated payment software. A practical approach for many businesses is to use an official payment provider and avoid storing sensitive card data in the event system itself.
Participants should see the total cost, payment validity period, and clear status. If payment succeeds but the confirmation page disconnects, participants can still check status via the order page or a secure link sent.
Minimum control: tickets are issued only based on a verifiable server confirmation, not just a “success” display on the participant’s device.
4. Ticket: Create Unique, Limited, and Revocable Identities
Digital tickets are not enough as a single QR image for everyone. Each ticket must be tied to the transaction identity, category, status, and usage rules.
The QR can contain a random identifier or signed token, not all personal data of the participant.
The server then checks:
- Whether the ticket was issued by the official system.
- Whether the ticket is still active.
- Whether the category and date match.
- Whether the ticket has been used.
- Whether the ticket was cancelled or transferred through official procedures.
- When and on which device the ticket was checked.
OWASP explains that signed tokens can be verified using the appropriate key.
However, tokens still require validity management and revocation.
A QR should not be considered secure just because its form is hard for humans to read.
If the process only reads the quota number and then subtracts it after payment, the system can sell tickets beyond capacity.
Use one primary data source for availability. When a participant selects a category, the system can create a temporary reservation with an expiration time. The quota is confirmed after successful payment and released again if payment does not complete.
Data that needs to be distinguished:
- Total quota.
- Available quota.
- Quota currently reserved.
- Payment pending.
- Ticket issued.
- Cancellation or refund.
- Quota intentionally held by the committee.
Every change must be consistent and traceable. Do not rely on separate spreadsheets for the public page, payment, and operations team because differing update times can cause conflicts.
Minimum control: a single participant cannot reduce the quota twice due to a button re‑press, page reload, or duplicate payment notification.
OWASP Cheat Sheet SeriesIf participants lose access to their email or tickets change, the committee requires a reissuance process that cancels the old ticket. Avoid sharing QR codes via public URLs that can be forwarded or logged.
Minimum control: each ticket has one identity, status, history, and clear validation rules.
5. Check‑in: Prepare Fast Scanning and Disruption Mode
Day‑of is a real test. A system that works well with five people may not be ready when many participants arrive simultaneously.
Design check‑in with:
- Multiple lanes by category or arrival time.
- A scanner app with a simple interface.
- Distinct indicators for valid, used, and problematic tickets.
- Timestamping and scanner device logging.
- Prevention of duplicate check‑ins.
- Manual search based on minimal data.
- Escalation procedures for problematic tickets.
- Network disruption and sync modes with clear risk limits.
Offline mode should not mean all QR codes are automatically accepted. Minimum validation data can be prepared securely, devices limited, and scan results re‑synced with conflict resolution mechanisms.
The committee also needs to measure field capacity: average scan time, number of devices, number of lanes, and participant arrival rate. Technology will not solve queues if the physical process design is inadequate.
Minimum control: the committee has procedures for when internet, devices, batteries, or central services fail.
6. Notifications: Send Information Based on Status and Time
Participants need different information at each stage:
- Account or order confirmation.
- Payment instructions.
- Payment success.
- Ticket issuance.
- Race pack pickup reminder.
- Schedule, location, entrance, and mandatory gear.
- Operational changes.
- Post‑event information.
Use transactional notifications triggered by system status, not manual sends that can be missed. Separate essential operational messages from promotions. Store delivery status, failures, retries, and channels used.
Do not rely on a single channel. Email is suitable for long information and proof, while WhatsApp, SMS, apps, or web notifications can be used with consent and urgency. Important messages should direct participants to a consistent official source.
Provide a “latest information” page so participants always have one reference if messages fail to arrive. When schedules change, update the source data first, then send notifications from the same version.
Minimum control: the committee can see what messages were sent, to whom, when, and whether delivery succeeded.
7. Dashboard: Combine Business and Operational Decisions
The event dashboard is not just decorative charts.
The dashboard should help the committee decide actions.Before the event, display:
- Registrations by category and sales phase.
- Available quota, reservations, and expirations.
- Successful, pending, and failed payments.
- Traffic sources and form completion ratios.
- System failures and queue processes.
- Undelivered tickets.
- Most frequent questions or complaints.
On the day, focus on:
- Number of participants who have checked in.
- Check‑in speed per lane.
- Duplicate or rejected tickets.
- Active and problematic devices.
- Help queues.
- Connection and sync status.
- Incidents and their owners.
After the event, the dashboard can aid revenue reconciliation, refunds, attendance rates, category performance, promo code usage, channel effectiveness, and service evaluation.
Each metric must have a definition. “Participant” can mean a registered account, an order placed, a successful payment, a issued ticket, or a person who actually attends.
Without a definition, the same numbers can be interpreted differently by marketing, finance, and operations teams.
Minimum control: dashboard data has a source, update time, definition, and clear action owner.
Controlled Digital Event System Flow
Example flow from start to day‑of:
- Visitor opens a fast, mobile‑friendly landing page.
- The system displays categories and the latest quota.
- Visitor fills a form with clear validation.
- The system creates an order and temporarily reserves quota.
- Participant is directed to the payment provider.
- The server receives and verifies payment notifications.
- Quota is confirmed and a unique ticket issued.
- The system sends proof of payment, ticket, and event information.
- Staff scans tickets at check‑in.
- The dashboard updates attendance and incident status.
- The finance team reconciles orders, payments, costs, and refunds.
- Change logs are stored for evaluation and dispute handling.
This flow must be tested, including scenarios of delayed payment, duplicate notifications, participants pressing a button repeatedly, ticket forwarding, check‑in network loss, and scanner replacement.
30‑Day System Preparation Plan
Week 1: Map flow and risks
Document the participant journey from information to check‑in. Define status, process owner, mandatory data, capacity, and the most impactful failure points.
Week 2: Build transaction foundation
Set up quota management, temporary reservations, order status, payment integration, unique tickets, and transactional notifications.
Implement secure authentication and session management for the committee and participants. OWASP recommends using secure cookies, server‑controlled session lifetimes, and re‑authentication after high‑risk events.
Week 3: Load and operation testing
Conduct load testing, simulate duplicate payment notifications, parallel check‑ins, slow networks, and service failures.
Train staff with the application and procedures that will actually be used.Week 4: Clean run and observability
Run end‑to‑end simulations. Ensure dashboards, alerts, logs, escalation contacts, backup devices, and status pages are available. Freeze major changes before the event except for tested fixes.
Errors to Avoid
- Using a single quota number across multiple systems without synchronization.
- Assuming a successful payment screen is the final confirmation.
- Issuing reusable tickets.
- Storing more personal or payment data than necessary.
- Sending critical changes through only one channel.
- Having no procedure when check‑in connectivity is disrupted.
- Displaying a dashboard without metric definitions.
- Making major system changes the night before the event.
- Testing the system only under normal conditions.
From JRF Trends to Reliable Event Systems
The surge in JRF searches shows the public’s strong interest in an event. For organizers and businesses, that attention must be matched with a system that delivers a consistent experience from the moment visitors open the page to participants passing through check‑in.
Asa Production helps businesses build event landing pages, registration systems, quota management, payment integration, digital tickets, check‑in apps, automated notifications, operational dashboards, and data integration as needed.
If your event process is still spread across forms, spreadsheets, chat, and manual checks, discuss a more measurable digital event system design through www.asaproduction.tech.
Asa Production — Build. Automate. Grow.
Note: This article is educational. Examples of controls should be tailored to the event scale, payment type, data processed, legal obligations, and each organizer’s risk assessment.
