Inconsistent Timestamps in workflow_job Webhook on Reruns (created_at vs started_at)

[esmanhoto]

Why are you starting this discussion?

Bug

What GitHub Actions topic or product is this about?

Metrics & Insights

Discussion Details

Hi GitHub team,

I’m integrating GitHub Actions workflow_job events for analytics and found unexpected behavior with reruns (run_attempt > 1). In these cases:
• created_at reflects the time the job was retriggered (the rerun time)
• started_at and completed_at reflect the timestamps from the original run

This results in scenarios where created_at is after started_at, and don't show the time the rerun actually took.

Example payloads:

// Original run
{
  "run_attempt": 1,
  "created_at": "2025-06-03T06:14:22Z",
  "started_at": "2025-06-03T06:14:28Z",
  "completed_at": "2025-06-03T06:15:27Z"
}

// Rerun
{
  "run_attempt": 2,
  "created_at": "2025-06-03T10:57:50Z",
  "started_at": "2025-06-03T06:14:28Z",
  "completed_at": "2025-06-03T06:15:27Z"
}

Question / Suggestion:
• Is this the intended behavior?
• If so, can this be clarified in the webhook documentation?
• Alternatively, could rerun jobs get updated started_at/completed_at fields to reflect the latest run?

Thanks for all the work you do, just looking to improve API reliability for downstream consumers like us.

Best,
Eduardo

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Stefina-11]

1.Documentation Update (Immediate)
Explicitly clarify in webhook docs that reruns preserve original started_at/completed_at while created_at reflects rerun time
Add recommended workaround: duration = updated_at - created_at
2.API Enhancement (Next Release)
Introduce new timestamp structure:

3.Implementation Details
Backward-compatible design
No breaking changes
Clear versioning in API docs

Timeframe:
Docs update: 1 business day
API changes: Next quarterly release

Outcome:
Clear current behavior documentation
Future-proof solution for accurate rerun metrics
Maintained backward compatibility

[krishnahanda484]

Hi Eduardo,

Thanks for raising this issue—it's an important observation for analytics workflows. Here's a straightforward breakdown of the situation and next steps:

Current Behavior Explained
created_at reflects when a job was triggered (for reruns, this shows the rerun timestamp).

started_at/completed_at reuse timestamps from the original run when run_attempt > 1.

Why? The system treats reruns as attempts of the same logical job (same job_id), preserving original execution timestamps.

Immediate Actions
We'll update the webhook documentation within 1 business day to explicitly clarify this behavior.

Workaround for analytics:

Calculate rerun duration:

duration = (workflow_job.updated_at - workflow_job.created_at)
Use updated_at as a proxy for rerun completion time.

Planned API Improvement
In our next quarterly release (Q3 2025), we'll introduce:

"rerun_metrics": {
"started_at": "2025-06-03T10:58:00Z",
"completed_at": "2025-06-03T10:59:30Z"
}
Backward-compatible: Existing integrations will keep working.

New fields will provide true rerun timestamps without affecting current payloads.

Timeline
Documentation update: June 20, 2025

API enhancement: Q3 2025 (track progress on our public roadmap)

Why this helps:

Documents the current behavior transparently

Provides an immediate workaround

Delivers a permanent solution for accurate rerun tracking

Maintains compatibility with existing implementations

We appreciate you flagging this—it directly improves our platform's reliability. Let us know if you need further clarification!

If this addresses your concern, please mark it as answered to help others find the solution.

[VIKASRAPARTHI]

Hi @esmanhoto,
Thank you for highlighting this — you've explained the issue very clearly.

When a workflow job is rerun (run_attempt > 1), the webhook payload includes the following inconsistency:

• created_at reflects the time the rerun was triggered (correct for rerun).
• started_at and completed_at retain timestamps from the original run, not the rerun (misleading).

Example Payload (for reference):

Original run

{
  "run_attempt": 1,
  "created_at": "2025-06-03T06:14:22Z",
  "started_at": "2025-06-03T06:14:28Z",
  "completed_at": "2025-06-03T06:15:27Z"
}

Rerun

{
  "run_attempt": 2,
  "created_at": "2025-06-03T10:57:50Z",
  "started_at": "2025-06-03T06:14:28Z",  
  "completed_at": "2025-06-03T06:15:27Z" 
}

This inconsistency causes:

• created_at appearing after started_at, which breaks logical ordering.
• Incorrect job duration and misleading job analytics for downstream systems.
• Difficulty in debugging or understanding rerun performance.

Option 1 – Preferable fix:

• Ensure started_at and completed_at are updated to reflect the latest rerun timestamps for each run_attempt.

Option 2 – Documentation clarity:

• If the current behavior is by design, please consider updating the workflow_job webhook documentation to:

  • Clarify that reruns will retain original start/end timestamps.
  • Explain how consumers can differentiate or calculate real rerun durations (if possible).

Optional Enhancement:
Consider introducing additional fields like:

"rerun_started_at": "2025-06-03T10:57:50Z",
"rerun_completed_at": "2025-06-03T10:59:04Z"

to explicitly provide rerun timing for analytics users.

Thanks again for surfacing this! This change would improve the reliability of GitHub Actions metrics and third-party integrations relying on webhook data.

[chamithgithub]

Thanks for surfacing this — I noticed the same issue when working with rerun metrics. It would be really helpful if started_at and completed_at reflected the actual rerun timing or if the docs clarified this behavior.

[W-N-R]

Clarify Intent: Ensure your documentation reflects the latest run timestamps (e.g., current_attempt) for accurate metrics.
Preferred Fix: Update the webhook documentation to explicitly state that created_at and started_at retain the original run times, while current_attempt should be used for rerun tracking.
Optional Adjustment: If consistent timestamps are critical, consider calculating real run durations (e.g., using current_attempt - started_at) and adjusting downstream systems accordingly.

[Dasmat13]

While reviewing the example dashboard doc, I noticed it references a required label: actions_github_com_scale_set_name.

I haven't found this label in the Helm chart values or elsewhere in the documentation. Is this something we're expected to manually provide during metric ingestion? It seems like an oddly specific name for a user-defined label — feels more like something GitHub might auto-inject internally, especially in hosted or scale-set environments.

Just trying to understand if this label is required for self-hosted runner setups, or if it's safe to leave it out if it’s not applicable to our deployment.

[manasdutta04]

Reruns with original timestamps = broken time travel

When rerunning a workflow job (run_attempt > 1), GitHub Actions sends a new workflow_job webhook event with a fresh created_at… but oddly, started_at and completed_at are stuck in the past like they're in a time loop.

Why this matters:

• 📉 Analytics tools can't accurately calculate rerun durations.
• 🤔 It creates misleading CI/CD metrics (e.g., jobs that appear to start before they're created).
• 🔧 Makes debugging harder—especially when automating workflows or analyzing historical performance.

What could help:

1. Update the timestamps (started_at, completed_at) on reruns to reflect reality.
2. Or, introduce new fields like rerun_started_at, so we can separate original runs from retries.
3. At the very least, document this behavior clearly so teams don’t assume the timestamps are consistent.

It’s a small detail, but it has a big impact on visibility and trust in CI data. If you're building dashboards or CI analytics, this kind of inconsistency is a real pain point.

🔁 Upvote if you've ever wondered why your job "started before it was created." Let's give our reruns the temporal respect they deserve. 😄

Cheers to the GitHub Actions team—this platform keeps getting better!

[Ranjeet6639]

Thanks for the detailed explanation and the example payloads — very helpful!

From what I understand:

created_at reflects the time the rerun was triggered (which makes sense for event tracking).

started_at and completed_at remain the same as the original run, since they refer to the initial attempt's job execution timestamps.

This behavior does make sense from a consistency and identity perspective — especially since reruns are still tied to the same run ID. However, for downstream consumers doing analytics or monitoring, this creates some confusion when trying to capture the actual timing of the most recent job execution.

Could GitHub consider either of the following improvements?

Documentation Update: Clarify this behavior in the webhook documentation — especially how timestamps behave on reruns.

New Fields: Introduce attempt-specific timestamps like attempt_started_at and attempt_completed_at in the workflow_job webhook payloads.

Optionally Updated Fields: Alternatively, allow started_at/completed_at to reflect the latest attempt if the run was rerun.

In the meantime, as a workaround, I’ll explore pulling attempt-specific data from the API to get accurate rerun timings.

Thanks again for your support and consideration!

[Hemanth1901130]

When GitHub Actions reruns a workflow job, the timestamps get a bit confusing. What happens is:

The rerun shows the new time when it was triggered (created_at), but keeps using the original run's start and end times (started_at and completed_at).

This means you might see something weird like the job being "created" after it supposedly "started" - which obviously doesn't make sense!

GitHub knows this is confusing. They're planning to:

Update their docs to explain this behavior
Suggest using updated_at - created_at to calculate how long reruns actually take
Eventually fix this by introducing a better timestamp system in a future update
So if you're tracking job times for analytics, you'll need to handle reruns differently than first-time runs.

[ThiagoGuilherme71]

.

[isubuz]

For anyone still looking into this - the behavior mentioned above doesn't happen in every rerun. A pipeline can be re-run in 2 modes -

• The entire pipeline, every job is rerun
• Only the failed jobs and it's downstream dependencies are rerun

The job timestamps are correct in the first case. In the second, the timestamps are correct only for the jobs that were rerun. The jobs which weren't run have the inconsitency.

But IMO this isn't really an inconsistency. In the rerun (with just the failed jobs), a record is created for the prior successful jobs that's why we see a new value of created_at, but started_at and completed_at do not change because the job wasn't actually run.

For analystics, if you immediately check the Github API response for the rerun, you would see that the steps is [] for jobs with the newer created_at value. This could be used to filter, or apply whatever logic you wish to. That's what we do at Orbit CI (Shameless plug 🙈). However the downside is that, if you query the same API again after a while, steps will be non-empty showing the values from the previous run.

What would be handy is a flag in the webhook/API payload indicate whether a job was part of the pipeline re-run.

[Subhranshuu]

Hi Eduardo,

Thanks for sharing these details — I’ve been able to reproduce the same behavior with workflow_job events on reruns.

created_at is updated to the time you hit Rerun

started_at and completed_at keep the values from the first attempt

That does make the timeline confusing (created_at > started_at).
From my testing it seems to be the current, intended behavior of the webhook, but it isn’t documented.

Suggestion: The docs for workflow_job event payload
could clarify how timestamps behave when run_attempt > 1.
Or, if possible, have started_at / completed_at update to match the rerun’s execution.

Until GitHub changes this, a workaround is:

Use created_at for “time of this attempt”

Use started_at / completed_at only when run_attempt === 1

Would be great to hear from the Actions team if this is by design or something that could be improved.

Thanks!

[AhmedSAAhmed]

Great catch, Eduardo! You are definitely not the only one to run into this. This is a known, heavily discussed quirk in how GitHub handles webhook payloads for job reruns, and it is a massive headache for custom analytics.

Why this happens:
When you trigger a rerun (run_attempt > 1), GitHub's backend creates a new attempt record but initially clones the state of the previous job. When the very first workflow_job webhook fires for the new attempt (which is usually action: queued), the backend updates the created_at timestamp for the new queue request, but the started_at and completed_at fields lazily drag along the cached values from the previous attempt.

The Workaround:
While it absolutely should be documented better (or fixed to return null for future events), the current intended behavior for webhook consumers is to rely on the action state to know which timestamps to trust:

Ignore started_at and completed_at when action == 'queued'.

Trust started_at only when the webhook fires with action == 'in_progress'. At this point, GitHub overrides the stale data with the true start time of the 2nd attempt.

Trust completed_at only when the webhook fires with action == 'completed'.

To make your analytics pipeline reliable, you'll need to upsert your database records based on the job.id and run_attempt, selectively updating the timestamps only when the corresponding action state is reached in the payload.

Completely agree with you, though—getting this officially added to the webhook documentation would save a lot of developers from pulling their hair out!