{
 "id": "eptp9z78zf",
 "slug": "runtime-monitoring",
 "title": "Runtime monitoring",
 "updated": "2026-10-15",
 "topic_path": [
  {
   "id": "technology",
   "label": "Technology and the built world",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology"
  },
  {
   "id": "technology.computing",
   "label": "Computing and digital systems",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing"
  },
  {
   "id": "technology.computing.software",
   "label": "Software and programming",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.software"
  },
  {
   "id": "technology.computing.software.software_engineering",
   "label": "Software engineering and development process",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.software.software_engineering"
  },
  {
   "id": "technology.computing.software.software_engineering.software-testing-and-quality",
   "label": "Software testing and quality",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.software.software_engineering.software-testing-and-quality"
  }
 ],
 "geo": [
  {
   "id": "geo.nongeo.t1946.technology.computing.software.software_engineering",
   "label": "Non-geographic · 1946 to 2000: Software engineering and development process",
   "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.software.software_engineering",
   "path": [
    {
     "id": "geo.nongeo",
     "label": "Non-geographic",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo"
    },
    {
     "id": "geo.nongeo.t1946",
     "label": "Non-geographic · 1946 to 2000",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946"
    },
    {
     "id": "geo.nongeo.t1946.technology",
     "label": "Technology and the built world",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing",
     "label": "Computing and digital systems",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing.software",
     "label": "Software and programming",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.software"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing.software.software_engineering",
     "label": "Software engineering and development process",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.software.software_engineering"
    }
   ]
  },
  {
   "id": "geo.nongeo.t2001.technology.computing.software",
   "label": "Non-geographic · 2001 to 2020: Software and programming",
   "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t2001.technology.computing.software",
   "path": [
    {
     "id": "geo.nongeo",
     "label": "Non-geographic",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo"
    },
    {
     "id": "geo.nongeo.t2001",
     "label": "Non-geographic · 2001 to 2020",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t2001"
    },
    {
     "id": "geo.nongeo.t2001.technology",
     "label": "Technology and the built world",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t2001.technology"
    },
    {
     "id": "geo.nongeo.t2001.technology.computing",
     "label": "Computing and digital systems",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t2001.technology.computing"
    },
    {
     "id": "geo.nongeo.t2001.technology.computing.software",
     "label": "Software and programming",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t2001.technology.computing.software"
    }
   ]
  }
 ],
 "excerpt": "Runtime monitoring, also known as runtime verification, observes a running program's execution against formally specified properties and produces verdicts, alarms, or recovery actions, with monitors able to steer the system into a safe state.",
 "snippet": "Runtime monitoring, also known as runtime verification, observes a running program's execution against formally specified properties and produces verdicts, alarms, or recovery actions, with monitors able to steer the system into a safe state.",
 "node": "technology.computing.software.software_engineering.software-testing-and-quality",
 "markdown": "# Runtime monitoring\n\nRuntime monitoring observes a running program's execution against formally specified properties and produces verdicts, alarms, or recovery actions while the program runs. A monitor reads the stream of events the program generates, decides whether the observed prefix still satisfies the property, and reports a truth value from a verdict domain, typically true, false, or inconclusive.<sup>[1](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/lectures/RV.pdf)</sup> Beyond passive checking, monitors can raise alarms, invoke user-defined handlers, or steer the running system into a safe state.<sup>[2](https://swtv.kaist.ac.kr/files/publications/international_conference/RV19-invited-MAC.pdf)</sup> The field is usually called [runtime verification](https://www.edgepedia.org/runtime-verification) (RV) when the emphasis is on checking a run against a specification, and runtime enforcement when the monitor intervenes to prevent violations; enforcement was initiated by security automata, which can enforce the whole class of safety properties.<sup>[3](https://www.irisa.fr/vertecs/Publis/Ps/STTT-2011.pdf)</sup>\n\n| Key fact | Value |\n|---|---|\n| Verdict semantics | Three-valued LTL\\(_3\\): \\(\\top\\), \\(\\bot\\), ? for finite prefixes of infinite traces<sup>[4](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/papers/RV.pdf)</sup> |\n| Monitorable properties | Strictly larger than the union of safety and co-safety properties<sup>[4](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/papers/RV.pdf)</sup> |\n| JavaMOP overhead | 15% average on the DaCapo benchmark after years of optimization<sup>[5](https://fsl.cs.illinois.edu/publications/jin-meredith-lee-rosu-2012-icse.pdf)</sup> |\n| Many-specs overhead | 143% (RV-Monitor) vs 163% (JavaMOP) average with 179 Java API specs monitored simultaneously<sup>[6](https://fsl.cs.illinois.edu/publications/luo-zhang-lee-jin-meredith-serbanuta-rosu-2014-rv.pdf)</sup> |\n| Testing-scale overhead | Mean 23.6x across 1,544 projects; 60.5% of RV time spent on instrumentation<sup>[7](https://www.cs.cornell.edu/~legunsen/pubs/GuanAndLegunsenRVOverheadStudyISSTA24.pdf)</sup> |\n| Log-scale monitoring | MonPoly processed over 26 billion events (0.4 TB) from two years of Nokia logs<sup>[8](https://people.inf.ethz.ch/basin/pubs/rvcubes17.pdf)</sup> |\n| In-kernel deployment | Linux ships an RV subsystem with per-cpu and per-task monitors and reactors<sup>[9](https://docs.kernel.org/6.19-rc7/trace/rv/runtime-verification.html)</sup> |\n\n## How it works\n\nA monitor is formally a device that reads a finite trace and yields a verdict, modeled as a tuple with a verdict domain, an event set, states, a deterministic transition function, and a verdict function.<sup>[10](https://www.cs.man.ac.uk/~regerg/papers/rv-tutorial-ios-2012.pdf)</sup> Two maxims govern verdict synthesis: impartiality, never deciding true or false while some continuation could yield the other verdict, and anticipation, deciding as soon as all continuations agree.<sup>[11](https://christian.schallhart.net/publications/2008--atva--impartial-anticiapation-in-runtime-verification.pdf)</sup> For LTL, the LTL\\(_3\\) semantics evaluates a prefix \\(u\\) to \\(\\top\\) if every infinite continuation satisfies \\(\\varphi\\), \\(\\bot\\) if every continuation violates it, and ? otherwise.<sup>[1](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/lectures/RV.pdf)</sup>\n\nMonitorability limits what can be decided. A safety property's failure is always detectable in finite time, but no finite prefix yields a positive verdict for \\(\\Box p\\), and for \\(\\Box\\Diamond p\\) no verdict is ever possible in finite time.<sup>[12](https://havelund.com/Publications/rv-2023-tutorial.pdf)</sup> The monitorable class strictly contains the union of safety and co-safety properties.<sup>[4](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/papers/RV.pdf)</sup> Monitor construction for LTL\\(_3\\) yields an automaton of size \\(\\lvert M \\rvert \\in 2^{2^{O(\\lvert \\varphi \\rvert)}}\\), minimizable via Myhill-Nerode; implementation styles include rewriting, alternating automata, and deterministic automata.<sup>[1](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/lectures/RV.pdf)</sup>\n\n## How it is done\n\nThe RV process has three stages: monitor synthesis from the property, system instrumentation to generate events, and execution analysis either in lock-step with the running system or post hoc from logs.<sup>[10](https://www.cs.man.ac.uk/~regerg/papers/rv-tutorial-ios-2012.pdf)</sup> [Instrumentation](https://www.edgepedia.org/instrumentation) techniques form a spectrum from completely asynchronous monitoring to completely synchronous monitoring.<sup>[13](https://ar5iv.labs.arxiv.org/html/1708.07229)</sup> The early MaC architecture used a filter, an event recognizer, and a run-time checker, with implementation-dependent events (PEDL) separated from high-level requirements (MEDL).<sup>[14](https://vmahesh.cs.illinois.edu/papers/ecrts99.pdf)</sup>\n\nOverhead has two components, information extraction (probes) and property evaluation, and depends on which program points are instrumented and on the monitor's data structures; more expressive formalisms cost more.<sup>[15](https://swtv.kaist.ac.kr/files/publications/international_conference/rv02a.pdf)</sup><sup> • </sup><sup>[10](https://www.cs.man.ac.uk/~regerg/papers/rv-tutorial-ios-2012.pdf)</sup> For first-order specifications, both event-rate independent and trace-length independent algorithms are unattainable: monitoring \\(p(x)\\) requires, in the worst case, memory proportional to the entire trace prefix.<sup>[16](https://people.inf.ethz.ch/basin/pubs/atva23.pdf)</sup> Responses range from alarms to recovery code: MaC's steering action changes the running system's state or invokes a recovery routine,<sup>[2](https://swtv.kaist.ac.kr/files/publications/international_conference/RV19-invited-MAC.pdf)</sup> and JavaMOP-generated monitors run user-defined handlers on violation or validation, allowing in-program enforcement.<sup>[5](https://fsl.cs.illinois.edu/publications/jin-meredith-lee-rosu-2012-icse.pdf)</sup>\n\n## Origin\n\nThe MaC project started within an ONR MURI grant funded during 1997 to 2002, and the Java-MaC tool was presented at the first Runtime Verification workshop in 2001.<sup>[2](https://swtv.kaist.ac.kr/files/publications/international_conference/RV19-invited-MAC.pdf)</sup> The RV meeting itself, initiated as a workshop in Paris, became a conference in 2010; the 2001 paper \"Monitoring Java Programs with Java PathExplorer\" received the Test of Time Award at RV 2018.<sup>[17](https://www.havelund.com/Publications/rv-2018-test-of-time.pdf)</sup>\n\nLater systems motivated by JPaX's limitations include Eagle and Mop (monitoring-oriented programming); Mop used Perl for instrumentation and other versions used AspectJ.<sup>[17](https://www.havelund.com/Publications/rv-2018-test-of-time.pdf)</sup> MOP was reported by Feng Chen and Grigore Roşu in 2007 at the Illinois Digital Environment for Access to Learning and Scholarship at the University of Illinois at Urbana-Champaign; they proposed that monitors be automatically synthesized from formal specifications and integrated into the program.<sup>[18](https://dl.acm.org/doi/10.1145/1297027.1297069)</sup> The first international [Competition](https://www.edgepedia.org/competition) on Runtime Verification (CRV 2014) was documented by Ezio Bartocci, Yliès Falcone, Borzoo Bonakdarpour, and colleagues in 2017 in the International Journal on Software Tools for Technology Transfer.<sup>[19](https://doi.org/10.1007/s10009-017-0454-5)</sup> TraceMOP and LazyMOP were reported by Kevin Guan, Marcelo d'Amorim, and Owolabi Legunsen in 2025 in the Proceedings of the ACM on Programming Languages.<sup>[20](https://doi.org/10.1145/3763183)</sup>\n\n## Variants\n\n**Java tools.** Java PathExplorer checked Java programs against LTL specifications via the Maude rewrite engine, alongside data race and deadlock detection algorithms drawn from Eraser and Visual Threads.<sup>[17](https://www.havelund.com/Publications/rv-2018-test-of-time.pdf)</sup> Java-MaC generated its filter, event recognizer, and checker from PEDL/MEDL specifications in a static phase.<sup>[21](https://vmahesh.cs.illinois.edu/papers/fmsd04.pdf)</sup> JavaMOP slices a trace by parameter instance and checks each slice with a dedicated monitor, remaining formalism-agnostic with plugins for FSM, ERE, CFG, PTLTL, LTL with simultaneous future and past operators, and PTCaRet.<sup>[5](https://fsl.cs.illinois.edu/publications/jin-meredith-lee-rosu-2012-icse.pdf)</sup> RV-Monitor improved simultaneous monitoring of many properties using indexing trees that hold weak references to avoid memory leaks.<sup>[6](https://fsl.cs.illinois.edu/publications/luo-zhang-lee-jin-meredith-serbanuta-rosu-2014-rv.pdf)</sup>\n\n**First-order and policy monitoring.** MonPoly checks logs and event streams against metric first-order temporal logic (MFOTL), restricted to a safety fragment with bounded future operators; its family later added aggregation, recursion, and distributed monitoring.<sup>[16](https://people.inf.ethz.ch/basin/pubs/atva23.pdf)</sup>\n\n**Other languages.** Larva uses the DATE automata language (Dynamic Automata with Timers and Events); Lola offers offline and completely synchronous online monitoring with bounded resource guarantees; detectEr monitors Erlang across several instrumentation modes.<sup>[13](https://ar5iv.labs.arxiv.org/html/1708.07229)</sup> CCMOP extends the MOP approach to C/C++ via the Clang compiler.<sup>[22](https://zbchen.github.io/files/rv2023.pdf)</sup> PyMOP is the first Python instance of MOP, with five logic plugins, parametric trace slicing, and online and offline monitoring.<sup>[23](https://arxiv.org/html/2509.06324)</sup> The Linux kernel's rvgen tool synthesizes monitors into C headers for deterministic automata, LTL, and hybrid automata.<sup>[24](https://docs.kernel.org/7.1/trace/rv/monitor_synthesis.html)</sup> Timed-property tools include MonPoly, Uppaal SMC, R2U2, Reelay, Montre, AERIAL, AMT, and RTAMT, and a 2026 Formal Methods in System Design article extends LTL\\(_3\\)-style three-valued verdicts to infinite timed words using timed Büchi automata and zone-based representations.<sup>[25](https://link.springer.com/article/10.1007/s10703-026-00498-5)</sup> Per one survey, 13 of 20 RV tools support some data in input specifications.<sup>[26](https://drops.dagstuhl.de/storage/00lipics/lipics-vol348-concur2025/LIPIcs.CONCUR.2025.4/LIPIcs.CONCUR.2025.4.pdf)</sup>\n\n## Applications\n\nLogScope was built to support testing of the flight software for JPL's Mars rover [Curiosity](https://www.edgepedia.org/curiosity), which landed on Mars on August 6, 2012.<sup>[17](https://www.havelund.com/Publications/rv-2018-test-of-time.pdf)</sup> In a Nokia case study, MonPoly checked compliance over log files with more than 26 billion events from a two-year period, 0.4 TB in protocol buffers format, using map-reduce to slice logs.<sup>[8](https://people.inf.ethz.ch/basin/pubs/rvcubes17.pdf)</sup> The Internet Computer, a distributed Web3 platform spanning over 1,200 nodes, was monitored with MonPoly using MFOTL policies with quantifiers, aggregations, and past and future operators; the pipeline alerts engineers of policy violations in the continuous development workflow.<sup>[27](https://internetcomputer.org/whitepapers/Monitoring%20the%20Internet%20Computer.pdf)</sup> Monitoring passing tests in thousands of Java projects against JDK API specifications found hundreds of bugs.<sup>[23](https://arxiv.org/html/2509.06324)</sup> The Linux kernel ships RV monitors with reactors such as nop, printk, and panic, exposed at /sys/kernel/tracing/rv/.<sup>[9](https://docs.kernel.org/6.19-rc7/trace/rv/runtime-verification.html)</sup>\n\n## Limitations and alternatives\n\nIncomplete or imprecise traces can leave a monitor unable to deliver a sound verdict; event-trace gathering and communication between system and monitor are where missing or ambiguous events arise.<sup>[28](https://dl.acm.org/doi/10.1016/j.cosrev.2023.100594)</sup> [Soundness and completeness](https://www.edgepedia.org/soundness-and-completeness) cannot be guaranteed when sampling is used or when observation order does not match execution order.<sup>[29](https://www21.in.tum.de/~traytel/papers/sttt21-tax_long/tax_long.pdf)</sup> One mitigation adds a \"give up\" verdict so the monitor abandons executions it can never conclude, relevant for autonomous systems with limited compute and memory.<sup>[30](https://iris.unimore.it/retrieve/4e63a873-ad18-429e-aac5-d6f17e0f725b/1-s2.0-S0167642324001436-main.pdf)</sup> Implicit-trace monitors like JavaMOP report only the last event of a violating trace, complicating debugging.<sup>[31](https://par.nsf.gov/servlets/purl/10628155)</sup>\n\nRV is not a comprehensive verification method like model checking; it is applied to executions one at a time, trading coverage for freedom from state-space complexity limits.<sup>[12](https://havelund.com/Publications/rv-2023-tutorial.pdf)</sup> It suits black-box settings with no model and offers polynomial-time behavior in trace length.<sup>[30](https://iris.unimore.it/retrieve/4e63a873-ad18-429e-aac5-d6f17e0f725b/1-s2.0-S0167642324001436-main.pdf)</sup> Runtime enforcement extends verification by circumventing violations rather than only detecting them.<sup>[3](https://www.irisa.fr/vertecs/Publis/Ps/STTT-2011.pdf)</sup>\n\n## References\n\n1. [Teaching Runtime Verification (lecture notes, Bonakdarpour, U. Waterloo CS745)](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/lectures/RV.pdf)\n2. [A Retrospective Look at the Monitoring and Checking (MaC) Framework](https://swtv.kaist.ac.kr/files/publications/international_conference/RV19-invited-MAC.pdf)\n3. [What can you verify and enforce at runtime?](https://www.irisa.fr/vertecs/Publis/Ps/STTT-2011.pdf)\n4. [Runtime Verification for LTL and TLTL (Bauer, Leucker, Schallhart)](https://cs.uwaterloo.ca/~bbonakda/teaching/CS745/papers/RV.pdf)\n5. [JavaMOP: Efficient Parametric Runtime Monitoring Framework (ICSE 2012)](https://fsl.cs.illinois.edu/publications/jin-meredith-lee-rosu-2012-icse.pdf)\n6. [RV-Monitor: Efficient Parametric Runtime Verification with Simultaneous Properties](https://fsl.cs.illinois.edu/publications/luo-zhang-lee-jin-meredith-serbanuta-rosu-2014-rv.pdf)\n7. [An In-Depth Study of Runtime Verification Overheads during Software Testing (ISSTA 2024)](https://www.cs.cornell.edu/~legunsen/pubs/GuanAndLegunsenRVOverheadStudyISSTA24.pdf)\n8. [The MonPoly Monitoring Tool](https://people.inf.ethz.ch/basin/pubs/rvcubes17.pdf)\n9. [Runtime Verification, The Linux Kernel documentation](https://docs.kernel.org/6.19-rc7/trace/rv/runtime-verification.html)\n10. [A Tutorial on Runtime Verification (Falcone, Havelund, Reger)](https://www.cs.man.ac.uk/~regerg/papers/rv-tutorial-ios-2012.pdf)\n11. [Impartial Anticipation in Runtime-Verification (Schallhart et al., ATVA 2008)](https://christian.schallhart.net/publications/2008--atva--impartial-anticiapation-in-runtime-verification.pdf)\n12. [Monitorability for Runtime Verification](https://havelund.com/Publications/rv-2023-tutorial.pdf)\n13. [A Survey of Runtime Monitoring Instrumentation Techniques (Francalanza et al.)](https://ar5iv.labs.arxiv.org/html/1708.07229)\n14. [Formally Specified Monitoring of Temporal Properties (ECRTS 1999)](https://vmahesh.cs.illinois.edu/papers/ecrts99.pdf)\n15. [Monitoring overhead / value abstraction paper (RV'02, Elsevier ENTCS)](https://swtv.kaist.ac.kr/files/publications/international_conference/rv02a.pdf)\n16. [Correct and Efficient Policy Monitoring, a Retrospective (MonPoly project, ATVA 2023)](https://people.inf.ethz.ch/basin/pubs/atva23.pdf)\n17. [Runtime Verification - 17 Years Later](https://www.havelund.com/Publications/rv-2018-test-of-time.pdf)\n18. [Mop: an efficient and generic runtime verification framework (OOPSLA 2007)](https://dl.acm.org/doi/10.1145/1297027.1297069)\n19. [Ezio Bartocci and colleagues (2017). First international Competition on Runtime Verification: rules, benchmarks, tools, and final results of CRV 2014. International Journal on Software Tools for Technology Transfer.](https://doi.org/10.1007/s10009-017-0454-5)\n20. [Kevin Guan, Marcelo d'Amorim, Owolabi Legunsen (2025). Faster Explicit-Trace Monitoring-Oriented Programming for Runtime Verification of Software Tests. Proceedings of the ACM on Programming Languages.](https://doi.org/10.1145/3763183)\n21. [Java-MaC: A Run-Time Assurance Approach for Java Programs](https://vmahesh.cs.illinois.edu/papers/fmsd04.pdf)\n22. [CCMOP: runtime verification for C/C++ programs (RV 2023)](https://zbchen.github.io/files/rv2023.pdf)\n23. [PyMOP: A Generic and Efficient Python Runtime Verification System and its Large-scale Evaluation](https://arxiv.org/html/2509.06324)\n24. [Runtime Verification Monitor Synthesis, The Linux Kernel documentation](https://docs.kernel.org/7.1/trace/rv/monitor_synthesis.html)\n25. [Efficient monitoring of timed properties (Formal Methods in System Design, 2026)](https://link.springer.com/article/10.1007/s10703-026-00498-5)\n26. [Monitorability for the Modal Mu-Calculus over Systems with Data (CONCUR 2025)](https://drops.dagstuhl.de/storage/00lipics/lipics-vol348-concur2025/LIPIcs.CONCUR.2025.4/LIPIcs.CONCUR.2025.4.pdf)\n27. [Monitoring the Internet Computer (FM 2023)](https://internetcomputer.org/whitepapers/Monitoring%20the%20Internet%20Computer.pdf)\n28. [Uncertainty in runtime verification: A survey (Computer Science Review, Vol 50)](https://dl.acm.org/doi/10.1016/j.cosrev.2023.100594)\n29. [Classifying Runtime Verification Tools (STTT)](https://www21.in.tum.de/~traytel/papers/sttt21-tax_long/tax_long.pdf)\n30. [Towards partial monitoring: Never too early to give in (Science of Computer Programming, 2024)](https://iris.unimore.it/retrieve/4e63a873-ad18-429e-aac5-d6f17e0f725b/1-s2.0-S0167642324001436-main.pdf)\n31. [TraceMOP / LazyMOP: Explicit-Trace Runtime Verification for Java (OOPSLA 2025)](https://par.nsf.gov/servlets/purl/10628155)\n\n---\n*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Software and programming › Software engineering and development process › Software testing and quality*\n\n*Initially written Sep 29, 2026 · Edited: Oct 15, 2026*\n\n*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*\n\nLicense: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license\n",
 "same_as": [
  "https://www.cs.cornell.edu/~legunsen/pubs/GuanAndLegunsenRVOverheadStudyISSTA24.pdf"
 ],
 "url": "https://www.edgepedia.org/runtime-monitoring",
 "markdown_url": "https://www.edgepedia.org/runtime-monitoring.md",
 "license": {
  "name": "Edgepedia Community License 1.0",
  "url": "https://www.edgepedia.org/edgepedia/license",
  "summary": "Free with credit, commercial use included. AI training is open to everyone. For other uses, organizations over USD 100M in revenue or 100M monthly users license separately.",
  "spdx": "LicenseRef-Edgepedia-Community-1.0"
 },
 "credit": "\"Runtime monitoring\", Edgepedia (EdgeChat), https://www.edgepedia.org/runtime-monitoring. Edgepedia Community License 1.0.",
 "credit_md": "\"[Runtime monitoring](https://www.edgepedia.org/runtime-monitoring)\", Edgepedia (EdgeChat), [https://www.edgepedia.org/runtime-monitoring](https://www.edgepedia.org/runtime-monitoring). [Edgepedia Community License 1.0](https://www.edgepedia.org/edgepedia/license).",
 "credit_html": "\"<a href=\"https://www.edgepedia.org/runtime-monitoring\">Runtime monitoring</a>\", Edgepedia (EdgeChat), <a href=\"https://www.edgepedia.org/runtime-monitoring\">https://www.edgepedia.org/runtime-monitoring</a>. <a href=\"https://www.edgepedia.org/edgepedia/license\">Edgepedia Community License 1.0</a>.",
 "speakable": "Runtime monitoring, also known as runtime verification, observes a running program's execution against formally specified properties and produces verdicts, alarms, or recovery actions, with monitors able to steer the system into a safe state."
}